Ethereum upgrade after Glamsterdam: what is actually decided in Hegotá

Ethereum's next major network upgrade is called Glamsterdam; the one that follows it carries the name Hegotá. Since August 16, 2026, a single figure has been travelling through the trade press: 66 proposals are said to be up for debate for Hegotá. Anyone who reads that as 66 new features arriving with the upgrade has misread the number. On that day, the official planning document maintained by Ethereum's core developers lists exactly one proposal that is firmly scheduled.

This article shows you where the gap comes from, how to read the planning document yourself, and how to tell whether an announced feature will actually land in the network. That skill is worth far more than today's headline. Before Hegotá is activated in its targeted year of 2027, you will read dozens of reports about supposed Ethereum features, a considerable share of which never go live. Every figure in this text comes from our own count of the official EIP documents on August 16, 2026.

What Hegotá is and where the upgrade sits on the Ethereum roadmap

An Ethereum upgrade is technically a hard fork: a change to the protocol rules that every node on the network has to adopt at the same moment. Anyone who does not follow ends up on a chain the others no longer track. That is why each such change is negotiated over months, tried out on test networks and only then given a fixed activation point. If you want to go back over the underlying machinery at your own pace, our explainer on how Ethereum works covers it.

The upgrades carry names with no descriptive meaning, which makes following along harder. Core developers are currently working on Glamsterdam, whose mascot, according to the planning document, is a polar bear. In parallel, preparation is under way for the upgrade that follows it, Hegotá. Each project has a steering document of its own, recording which individual change sits in which state. For Glamsterdam that is EIP-7773, created on September 26, 2024. For Hegotá it is EIP-8081, created on November 11, 2025. Both still carry the editorial status "Draft".

What Glamsterdam contains, and why the upgrade is considered particularly consequential, we wrote up in our piece on Glamsterdam and the Ethereum price from April 5, 2026. Hegotá is its successor and stands today roughly where Glamsterdam stood some two years ago.

Why the selection phase matters to you as an ETH holder

It would be convenient to file this away as a developer topic. That does not hold up, because a hard fork changes computing fees, transaction types and validator duties for everyone at once. Two examples from the list already firmly scheduled for Glamsterdam make it tangible: EIP-8037 and EIP-8038 raise the gas costs for writing and reading state data, and EIP-7981 makes access lists more expensive. Anyone working heavily with smart contracts will pay different fees afterwards.

Staking ETH is affected as well. EIP-8061 on the Glamsterdam list raises the ceiling on how many validators can exit or be consolidated per unit of time. That helps determine how long you wait for your balance when you unwind a position. If you draw your rewards through a provider and want to know which terms apply there right now, you will find the side-by-side view in our comparison of staking platforms; provider payout periods and protocol rules are two separate brakes that act independently of one another.

For you as a holder who simply buys ETH and leaves it alone, the calculation is simpler: your trading platform has to update its nodes in time, otherwise deposits and withdrawals stall around the activation date. That is precisely why exchanges announce maintenance windows ahead of every hard fork. If you want to know how steadily your own platform handles such transitions, and what fees it charges along the way, the overview is in our comparison of crypto exchanges.

The hard fork meta document EIP-8081 is the only binding list

For every upgrade the core developers create what is known as a meta EIP. It contains no technology, only a stocktake: which individual proposals are up for debate, which are being examined, which are firmly scheduled and which have been rejected. The authors listed for EIP-8081 are Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo and Parithosh Jayanthi, the same group responsible for the meta documents of the previous upgrades.

This document matters because it is the only place where an assignment is recorded bindingly. A contribution to a discussion forum, a talk at a conference or a post on a social network says nothing about whether a change is coming. Only once somebody submits an edit to the meta document and that edit is accepted does the proposal have an official state. You can look at the complete document yourself at any time: EIP-8081, Hardfork Meta Hegotá.

The count from August 16, 2026: one scheduled EIP, 37 proposals

We pulled the raw document from the Ethereum developers' source repository and counted the entries in each section. The request returned code 200, and the count produces the following picture.

The most telling number in this list is the zero. As long as not a single proposal has been rejected, the selection has not begun. That matches the description in the trade press, according to which the core developers intend to start cutting in the coming calls. For you it means this: of the 37 submitted proposals, the large majority will not land in this upgrade, and nobody today knows reliably which ones they will be.

The four stages under EIP-7723 and what they actually promise

The terms in the meta document are not figures of speech but defined states. They are set out in a document of their own, EIP-7723, titled "Network Upgrade Inclusion Stages", created in June 2024 and now at the status "Last Call". Anyone able to keep these four terms apart reads every future upgrade report more reliably than most headlines convey it. You can look up the definitions here: EIP-7723, Network Upgrade Inclusion Stages.

Proposed for Inclusion is only an application

To lift a proposal to this stage, it is enough to submit an edit to the meta document that adds the entry. No approval from the core developers is required, no finished implementation and no tests. The document merely records that somebody is proposing the change for this upgrade and stands available as a contact. All 37 entries currently sitting under this heading at Hegotá have therefore been through nothing more than a submission.

Considered for Inclusion is a statement of intent, not a commitment

A proposal reaches this stage after the developer teams have looked at it and express the intention of trying it on a test network. EIP-7723 explicitly compares the state to a "concept ACK" from other open-source projects and writes in the same paragraph that this state is not sufficient for deployment on the main network. From here a proposal can move back into rejection at any time, should the teams decide against it.

Scheduled for Inclusion requires measured maturity

Only this stage means that a proposal is on its way to the main network. EIP-7723 names four tests for it: the proposal ran on a test network that worked stably for at least a week and showed no critical faults. The specification contains no placeholders and no open drafting questions. Interactions with other proposals are either minor or were checked on that same test network. And test coverage is sufficient, without the software of different vendors diverging from one another. Even after all that, the assignment holds only "subject to unforeseen issues", and removal remains possible from here as well.

One practical side effect of the rules is worth remembering: as soon as the meta document moves from "Draft" to "Review", the lists of proposals and of rejections are removed from it. On the move to "Last Call", the list of examined candidates disappears too. On its way to completion the document therefore gets shorter, not longer. If you call it up again in a few months and suddenly find only a short list, that is a sign of progress and not a fault.

FOCIL (EIP-7805) is the only fixed component of Hegotá

The one proposal already firmly scheduled for Hegotá carries the number EIP-7805 and the abbreviation FOCIL, written out as "Fork-choice enforced Inclusion Lists". It was created on November 1, 2024, and the authors listed are Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann and Jihoon Song.

The problem FOCIL addresses is described plainly by the specification itself: the right to build blocks is today auctioned off to specialised providers. As a result, a small number of these builders dominate block production, and the network's resistance to censorship has suffered for it. In practice that means a block builder can filter out a transaction, perhaps because it touches a sanctioned address, and you have no claim that another builder will pick it up.

The mechanism works in four steps. In each time slot a group of validators is designated as a committee; every member assembles an inclusion list from its own view of the transaction pool and distributes it across the network. The proposer of the next block and all attesters collect these lists and pass them on. The block producer has to include the transactions from all the collected lists in its block. And the attesters vote for the block only if it has done so. A request thereby becomes a condition.

For you as a user, that is the difference between "my transaction will probably be included" and "my transaction has to be included". For validators the list of duties grows, because committee service comes on top of existing operations. Anyone who has staked ETH through a service provider should check in advance how that provider handles new protocol duties; the current terms of the providers are in our staking comparison.

Frame Transaction (EIP-8141) carries the privacy strand

The second entry with a state of its own is EIP-8141, named "Frame Transaction", created on January 29, 2026. The author list is unusually long and includes, among others, Vitalik Buterin, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Stavros Vlachakis and Toni Wahrstätter. At Hegotá the proposal sits at the stage "Considered for Inclusion" and is currently the only entry there.

In substance it introduces a new transaction type whose validity check and whose fee payment can be defined freely. To that end the transaction breaks down into individual sections, known as frames, which handle the check, the release of the fee and the actual execution one after another. The specification names several reasons for it: a move away from the elliptic-curve procedure used today towards procedures that also hold up against quantum computers; the decoupling of an account from its key, which makes a key change possible within the protocol itself; simpler and therefore safer smart contract accounts with batch processing built in; and alternative fee models without intermediary service providers.

The point about the key change deserves attention if you hold your own coins. Today an account hangs inseparably on one key pair; if the key is lost or falls into the wrong hands, the address is burned. A key change anchored in the protocol would loosen that logic. Until then, storing the key remains the decisive link, and a hardware solution is still the soundest route for it; which devices differ, and in what respect, is set out in our hardware wallet comparison.

What "native privacy" actually means in the document

The reporting from August 16, 2026 names three proposals that together are meant to enable privacy applications without a middleman: the Frame Transaction plus EIP-8250 ("Keyed Nonces for Frame Transactions") and EIP-8272 ("Recent Roots for Frame Transactions"). The claim goes back to a post by the developer Toni Wahrstätter.

In the meta document itself the picture looks more sober. Of these three proposals, one holds the state "Considered for Inclusion"; the other two sit under "Proposed for Inclusion" and have therefore been through no examination. A fourth entry with a direct bearing on the subject, EIP-8182 "Private ETH and ERC-20 Transfers", likewise appears only among the proposals. The package that shows up in headlines as a privacy push consists, in the official document, of one examined and three unexamined entries.

This distinction is not hair-splitting. Whether you can count on a feature in two years' time depends on it. And it can be checked in thirty seconds, because the document is public.

66 proposals in the media, 39 entries in the document

That leaves the question of where the number 66 comes from when the document holds 39 entries. Two trade outlets reported on it on August 16, 2026, Cointelegraph and crypto.news, and both refer to the same post by the developer named above on a social network. We were not able to view that post ourselves and therefore reproduce the number expressly as a media claim. Only the values from the meta document have been verified and counted by us.

The most likely reason for the difference lies in what is being counted in each case. The meta document carries only what somebody has formally submitted. In the developer calls and in the discussion forum, further proposals circulate that have not yet taken that step. Both numbers can therefore be correct and still measure different things. For you as a reader, one simple test follows: a number without its accompanying stage says nothing. With every upgrade report, ask first how many proposals are firmly scheduled, and only then read on.

Glamsterdam as a yardstick: 19 scheduled and 41 declined EIPs

How sharply the selection thins things out in the end is shown by a look at the upgrade that precedes Hegotá. The same count, applied to the Glamsterdam document EIP-7773 on August 16, 2026, yields 19 firmly scheduled proposals, seven further entries in secondary categories for network protocols and analyses, and 41 expressly declined proposals. At Glamsterdam, in other words, more was sorted out than taken on.

Among the firmly scheduled Glamsterdam proposals are changes with noticeable effect, such as EIP-7732 on anchoring the separation of proposers and block builders in the protocol, EIP-7928 on block-level access lists and EIP-7954, which raises the permitted size of a smart contract. What of that is really activated in the end is settled here too only at activation.

One detail on the margin is particularly instructive. Three proposals that were declined for Glamsterdam reappear in the Hegotá document as proposals: EIP-7668 on removing the bloom filters, EIP-7819 on the SETDELEGATE instruction and EIP-7979 on new call and return instructions for the virtual machine. That is expressly provided for. EIP-7723 records that a rejection only ever applies to a single upgrade and does not prevent another run at the next one. A rejection is therefore no final verdict on an idea, only a decision about a date.

The timetable: Glamsterdam 2026, Hegotá 2027, both without a fixed date

On dates the documents hold back conspicuously, and that is the most honest piece of information in the whole process. Both meta EIPs contain a table of activation times for the test networks and the main network. In both documents every field of that table is empty. Below it stands the note that the rows will be filled in once the developer teams have settled the timings.

What information does exist comes from the reporting and from the project's public roadmap: Glamsterdam is expected to reach the main network in the second half of 2026, and the core developers are aiming for Hegotá in the following year. As the next date for a developer call, Cointelegraph names Monday, 14:00 UTC. We could not verify that date against the primary source and therefore carry it as a media claim.

For your planning it means this: there is currently no date you could rely on, and every report naming one should prompt you to check. How the price discussion around Ethereum has developed independently of all this you can read in our Ethereum analysis from June 27, 2026; today's text deliberately contains no statement about future prices.

How to follow the Ethereum upgrade selection yourself, without waiting for headlines

The good news on this subject is that you do not have to rely on anyone. The document is public, short and checked in a few minutes. One pass looks like this:

1. Call up EIP-8081 and ignore the prose at first. What matters are the section headings alone and the number of entries beneath them.
2. Count the entries under "Scheduled for Inclusion". That number is the solid core of every upgrade report.
3. Look at whether anything stands under "Declined for Inclusion". If that list is growing, the selection has begun. If it stays empty, everything is still open.
4. Glance at EIP-7773 to see what lies ahead of Hegotá in time and what state it is in.
5. Check the editorial status of the document in the header at the top. A move from "Draft" to "Review" means the list of proposals has been removed and the matter is becoming more concrete.
6. Look at the activation table. As long as empty fields stand there, no agreed date exists, whatever is written elsewhere.

Anyone who has made this pass twice needs barely five minutes for it the third time. The gain is considerable: you can place any report about a coming Ethereum feature within a short time, instead of having to take it on trust.

Limits of this count: what the meta document does not answer

So that you know how far the figures in this text carry, here are the constraints in plain terms. The count is a snapshot from August 16, 2026. Every accepted edit to the document shifts the values, and in an active selection phase that happens several times a week.

The document also says nothing about how far implementation has progressed in the individual software products. That information sits in the test network reports and in the minutes of the developer calls, not in the meta EIP. It says just as little about which of the 37 submitted proposals stands any chance at all; anyone claiming otherwise is interpreting rather than reporting.

The number 66 we did not, as set out above, check at its original source. And finally: a network upgrade is not a price event. Neither the number of proposals nor their state says anything about the value of ETH, and this article expressly derives no expectation from it.

Placing an Ethereum upgrade: what to take away

1. Count the firmly scheduled proposals, not the discussed ones. At Hegotá that number stands at one today, at Glamsterdam at 19. Everything beyond it signals intent and settles nothing. If you take the technical development as an occasion to build up or reshuffle your holdings, compare the fees and the trading pairs of the providers first in our exchange comparison.
2. Before every hard fork, check what your provider does with it. Maintenance windows, suspended withdrawals and changed exit periods hit you in practice earlier than any protocol change. That becomes particularly relevant if you draw rewards; you will find the terms of the providers in the staking comparison.
3. Keep custody in your own hands. As long as a key change does not exist in the protocol, everything hangs on storing your key safely. Which devices differ, and how, is set out in the hardware wallet comparison.

(As of August 16, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)