Ethereum's next upgrade, Glamsterdam, has been scheduled for activation on the Hoodi testnet, but the mainnet date has not yet been determined. After completing activation on Sepolia, Ethereum developers set Hoodi's activation for October 26. The next test will simultaneously evaluate block production, state access, and gas changes, after which client teams will decide on the mainnet date.
- Glamsterdam was activated on Sepolia on October 6 and is scheduled to be activated on Hooi on October 26 at 17:42:48 UTC.
- According to the Ethereum Foundation, Hoodi's gas limit will be raised to 200 million within the same epoch.
- EIP-7732 incorporates the exchange between proposers and builders into the consensus protocol and introduces a new payload expiration obligation.
- EIP 7928 provides a block access list to enable clients to parallelize reading and validating more work.
- There is no activation date set for the mainnet yet, and prior to the network fork, the operator requires compatible execution and consensus layer clients.
On October 16, the Ethereum Foundation announced that Glamsterdam will activate on the Hoodi testnet on October 26 at epoch 132,352, corresponding to slot 4,235,264; however, the mainnet date has not yet been determined. This announcement followed the activation of Sepolia on October 6. Client teams still need to confirm compatible versions of the execution and consensus layers. The published schedule represents only the next test, not the official mainnet deployment date for these changes in Ethereum’s real economic environment.
Glamsterdam encompasses a variety of changes that cannot be simply summarized as "speeding up." It alters how proposers and builders exchange block payloads, introduces block-level state access lists, reprices operations that create or read on-chain state, and adjusts other execution layer and validator rules. Testnets can verify whether these components work together across different clients and applications, but they cannot prove that the mainnet can safely support higher gas limits under real financial loads.
October 26 is only a testnet commitment.
The Hoodi activation time in the announcement is October 26 at 17:42:48 UTC, corresponding to epoch 132,352 and slot 4,235,264. The foundation stated that Hoodi’s gas limit will be raised to 200 million in this epoch, aligning with Sepolia. However, the mainnet entry in the published activation schedule remains undetermined. Readers should not treat testnet times as a direct countdown to Ethereum mainnet, nor assume that the same gas limit will immediately apply to mainnet.
Before activation, Hoodi operators must use both an execution client and a consensus client version that are explicitly supported for this fork. Validators also run a validator client in addition to their beacon node. The foundation has listed versions confirmed by several teams and states that remaining entries will be updated continuously. The absence of a version in the table does not mean the team has abandoned the fork; it simply means operators should wait for an officially compatible version rather than guessing based on version numbers.
Network upgrades require node operators to actively participate by updating their software. Nodes continuing to use the old rules will be unable to follow the upgraded chain after the fork. Therefore, what matters next is not merely whether the scheduled slot has been reached, but whether multiple independent implementations can agree on the resulting chain, accept the same blocks, and recover smoothly under real-world edge cases. The success of testnet should be evaluated within this operational context.
Crypto.news previously reported on Sepolia’s schedule prior to its initial activation. Sepolia has now passed that milestone; Hoodi is testing another environment with a higher public gas limit. The authoritative sequence to follow after October 26 is the foundation’s announcement regarding the mainnet, client release guidance, and post-fork observations.
New handoff between block builders and proposers
Ethereum validators are responsible for proposing blocks, but specialized builders can assemble the execution payload. Currently, most exchanges between these roles occur via infrastructure outside the core consensus protocol. EIP-7732, known as "Embedded Proposer-Builder Separation," incorporates commitment, disclosure, and proposer payment logic directly into protocol rules. The proposer first commits to the builder’s payload, after which the builder discloses it under specified conditions.
The EIP 7732 specification outlines the new structure and timing for this exchange. Its goal is to reduce reliance on trusted middleware to facilitate basic builder-proposer payments and handoffs. However, it does not imply that all relays or private arrangements will disappear. The Ethereum roadmap’s note on Glamsterdam states that participants may still opt for external services for functionalities beyond the new protocol mechanism.
The Payload Timeliness Committee has added a new responsibility: members must verify whether builders have disclosed their payloads on time and whether the corresponding blob data is available. Consensus verification and execution verification occur at different times. This arrangement is designed to give validators more time to verify the computationally intensive execution work while ensuring the consensus process proceeds promptly. Builders must meet the new interface requirements and deadlines; validators must identify whether a committed payload has failed to arrive on time.
Failure scenarios are just as important as successfully completed blocks. Builders may withhold payloads, delay disclosure, or submit data that produces inconsistent results across different clients. The protocol must clearly define outcomes rather than leaving validators to guess which chain to follow. Hoodi provides clients with a public environment to test these paths and allows operators to observe whether builders and validator software adhere to the same rules.
Embedded handoffs also introduce economic issues. Removing trust from the core payment step may lower one barrier for builders, but this does not prove that block building will become more competitive. Builder concentration, order flow acquisition, and infrastructure costs must be measured after deployment. A new protocol can formalize roles, but it cannot guarantee that markets for executing these roles will become decentralized.
Block access list and tasks required by the node
EIP-7928 introduces block-level access lists that record the accounts and storage locations accessed within a block, along with state changes after transactions. Currently, validators must independently discover partial dependencies when processing blocks. With a verified access list, clients can schedule disk reads and partial validation tasks in parallel when operations do not conflict. This list is a protocol object, not a prediction published by an external data provider.
EIP-7928 defines the data and checks required for block-level access lists. Its expected benefits are practical: if every additional unit of block gas forces each node to follow the same lengthy serial path, execution cannot scale sustainably. Access data can shorten the slowest part of verification, provided builders generate accurate lists and clients reject inconsistent ones.
However, the list itself also increases data volume. If implementation is inefficient, larger blocks, complex state access, and network transmission overhead may offset the benefits. Parallel reading does not mean each transaction can be executed independently; two calls accessing the same storage location still have a defined order. Changes to the testnet gas limit will not automatically reduce fees for regular users by a fixed percentage. Fees depend on space requirements and the capacity provided.
The foundation views the block access list and the new builder submission mechanism together as foundational to increasing L1 throughput while preserving the feasibility of validation. Nodes with limited hardware capabilities serve as useful test cases for this claim. If only high-end operators can keep up with block propagation or state access under higher loads, the apparent capacity gains could strain the range of participants able to verify the chain. Post-Hoodi client performance and diversity are more important than the raw gas limit number.
Crypto.news previously discussed the trade-offs of access lists in its reporting on the upgrade design. The specific feature is the verified input, while targets like 200 million gas refer to testnet settings. Separating these in reporting clarifies which specific change improved performance.
Gas prices vary depending on the type of work.
Glamsterdam not only restructures blocks but also reprices operations. EIP-8037 increases and separately measures the cost of creating state; EIP-8038 updates state access fees. Other included proposals modify base gas costs, calldata costs, access lists, and block gas accounting. A simple transfer, a complex contract deployment, and a state-heavy application will not experience cost changes in the same direction or magnitude.
The fee repricing impact guide states that after replaying historical mainnet transactions under the proposed rules, a small number of contracts were found to rely on gas assumptions that may fail or degrade in performance. The guide notes that most flagged cases can be resolved by increasing the gas limit, and the vast majority of contracts were unaffected by this analysis. Historical replay can only identify potential candidates and cannot account for every future call or application state.
Developers should pay particular attention to fixed gas subsidies, hardcoded limits, and code that makes decisions based on remaining gas. A transaction that previously succeeded may now fail due to its workload exceeding its allocated limit after reallocation, even if the underlying logic remains correct. Fee estimation applications must account for the new rules to avoid preventable transaction failures. The foundation states that it has begun reaching out to the most affected builders.
Previous reports on wallets and gas tools highlighted a specific case: ordinary ETH transfers to existing accounts still incur the familiar 21,000 gas, while creating new accounts increases state fees. The roadmap indicates that some routine operations may become cheaper, while state creation will become more expensive. The average network fees observed after the mainnet launch cannot be attributed solely to this rule without considering activity levels, block demand, and base fees. Lower base gas requirements may benefit certain types of transactions, but if the chain becomes busier, the additional capacity could be quickly consumed. Prematurely declaring overall fee reductions overlooks this distinction.
The foundation's announcement on Hoodi lists EIP-7773 as a meta-proposal encompassing 18 major EIPs. Some of these changes are more intuitive for application developers, such as ETH transfer logs, slot number opcodes, and increased maximum contract size. Others will alter validator rotation or exclude slashed validators from proposer duties. The larger the combination, the more critical it becomes to conduct integration testing: while clients may implement each feature individually, inconsistencies may still arise among nodes when multiple features simultaneously affect the same block.
Hoodi's 200 million gas limit does not equate to a throughput commitment.
The block gas limit is the maximum amount of execution resources that a block can consume under established rules. Doubling this numerical limit does not necessarily mean that transaction throughput doubles or that the cost of a single contract call is halved. The gas rules in Glamsterdam themselves will change, and transaction composition is also crucial. A transaction that uses more gas under the new billing model may consume a larger portion of the limit, even if the application behavior remains unchanged.
Previous reports on the Sepolia 200 million gas test have established an earlier testnet configuration. On October 26, Hoodi’s changes will set the cap at 200 million at the fork epoch. This stress setting can expose propagation delays, slow execution, state access bottlenecks, and clients unable to process the heaviest blocks in a timely manner. The economic demands of the testnet differ from those of mainnet; it may require specially designed transactions to reach the upper limit of the allowance; otherwise, a very high cap may remain largely unused.
In contrast, the most informative metrics should include: the proportion of blocks that actually reach the cap, the time different clients take to process payloads, missing or delayed builder disclosures, attestation performance, and any on-chain disagreements. A single successful block below the cap does not prove that a node can frequently handle blocks close to the cap. Conversely, testnet failures may simply reflect fixable implementation issues rather than an invalid scaling design.
The foundation did not set a mainnet gas limit in this Hoodi notice. Ethereum validators can express their preferences for gas limits under network rules; the testnet schedule and mainnet activation choices are two separate matters. When reporting upgrades, clearly specify which number belongs to which network and when it will take effect.
Why testnet results may be misleading
The public testnet is a observable network environment where developers, validators, and individuals specifically seeking bugs participate to test protocol consistency. Its value lies in the requirement that different client implementations must accept the same state transition at the same slot. However, it remains an imperfect substitute for the mainnet. Testnet assets have no comparable market value, so malicious actors may take risks that would be costly on the mainnet. Some applications also do not deploy identical contracts or generate the same traffic patterns on both networks.
A smooth activation may mask the fact that the workload is unremarkable. If most of Hoodi’s blocks are far below the 200 million gas limit, then the limit itself reveals little. Client teams can construct or solicit high-intensity workloads, but synthetic stress transactions may interact with state in ways different from real-world exchanges, lending markets, or rollup settlements. Post-fork reports should show the distribution of block sizes, execution times, and missed duties, along with details of the workload used. Without a maximum sample size, the system may appear better than it actually is.
Multiple clients are also a variable. The network may still continue producing blocks because the dominant software operates normally, while a less commonly used implementation lags behind. Ethereum’s resilience partly depends on independent teams arriving at the same results. Hoodi’s observation should distinguish between client versions and bug reports, rather than treating a single chain head as sufficient proof of compatibility. If clients differ in their understanding of access lists or builder payloads, the cause must first be identified before scheduling a production fork.
Testnet users may also act maliciously. The warning about builder withholding occurs because builders can win bids using low-cost testnet assets and repeatedly fail to disclose payloads. Under the new rules, the network should continue to consistently enforce payload timeliness. Such attacks serve as beneficial stress tests of the mechanism, rather than being grounds for judging only the average block completion rate. The key is whether failures are contained and whether clients agree on the prescribed recovery path.
Finally, deployment readiness also includes infrastructure beyond consensus specifications. RPC providers, block explorers, builders, staking services, and contract monitoring systems must all understand the new logs, access list information, and deadlines. Testnet nodes may remain synchronized while wallets report unsafe gas limits. Therefore, mainnet readiness is not a simple “yes/no” on the foundation’s activation checklist, but rather a set of verifiable claims by different operators.
Who must update the software, and who doesn't have to
Hoodi validators face the most immediate operational deadlines. Their execution client, beacon node, and validator client all require compatible versions, and any builder tools must also understand the new transition process. Even non-staking Hoodi nodes still require both execution and consensus layer clients. Builders and relays should also verify their interfaces, even if they are not responsible for attesting to blocks. Misconfigured software may miss duties or fail to follow the upgraded testnet.
Ordinary mainnet ETH holders do not need to take any action due to Hoodi’s announcement. The foundation has clearly stated that mainnet activation will be notified separately. Wallet and application teams can use this testnet interval to test gas estimation, logs, new opcodes, and contract edge cases. None of these require users to transfer funds to the testnet or sign so-called upgrade transactions.
Concerns about builders abusing the test environment remain relevant. A credible ePBS test requires both honest and faulty builder behaviors, along with diverse clients, rather than focusing solely on idealized block sequences. Security efforts also include establishing bug bounties for the specification and qualified client implementations, progressing as release versions are added to the foundation’s table.
The public testnet also introduces coordination costs: client teams release binaries, operators update them, tool providers adapt their tools, and application teams retest. Setting a mainnet date before compatible clients and infrastructure are ready introduces avoidable risks. If the mainnet date remains undetermined for an extended period after a successful Hoodi fork, it may indicate that less visible components still require work; the activation alone cannot fully explain the entire decision timeline.
Prices and rollup claims require separate evidence.
An upgrade can enhance the network's technical capacity, but it does not mean that demand for ETH will significantly increase on the day it goes live. A successful testnet fork does not automatically result in distributions to token holders. Builders may invest in equipment, validators may update their software, and applications may adjust gas settings—these are all operational changes, not direct purchases of the token. Within the same week, macroeconomic conditions and position adjustments may also dominate market prices.
Layer 2 networks are also a place where expectations often outpace measurements. The new block commitment mechanism is designed to provide more time for verification and to support progress toward higher data availability. However, the cost of rollups depends on the price and supply of the data capacity they use, their packaging choices, and the demand from their own users. The activation of Hoodi does not reveal future mainnet blob prices, nor does it guarantee that every rollup will pass savings on to its users.
Similarly, a higher L1 gas limit may accommodate more transactions, but user fees depend on how much space others want to use. During periods of low demand, fees may appear cheap even without upgrades. A surge in transactions could fill more capacity and keep base fees elevated. A fair comparison should examine similar workloads before and after production changes, adjusted for usage. Fees paid on testnets with worthless assets cannot substitute for this analysis.
Even without recent price predictions, developers have reasons to pay attention to these changes. Contracts that fail to estimate gas may get stuck transactions; validators that fail to follow forks may miss rewards; builders that miss disclosure windows may lose block opportunities. These consequences can all be measured in testing. Simply knowing the activation date or gas limit configuration does not guarantee that ETH will rise or that Ethereum fees will decrease by a fixed proportion.
What counts as progressing toward the mainnet?
The optimal scenario is: Hoodi activates on the designated slot, independent clients remain synchronized, payload validity holds under pressure, and the access list helps maintain executability under higher gas usage. Contracts flagged by the repricing test are updated or assigned a safety execution cap. Subsequently, each team publishes mainnet deployment plans with dates and compatible client versions. This process transforms engineering design into an executable production plan.
The opposite scenario is equally concerning: payload responsibilities may make it difficult for validators or builders to coordinate; large access lists could slow propagation; and repricing might reveal more flawed assumptions than historical replay. Testnets may appear stable under low demand, but weaknesses could emerge when participants deliberately approach new limits. These factors mean that testing should be extended, an EIP should be modified, or mainnet configurations adjusted—rather than providing unfounded calendar dates.
The October 16 announcement from the foundation did not include an official mainnet activation date. The general expectation for the fourth quarter in the roadmap is merely a planning window, not an adopted fork slot. The next verifiable milestone will be the Hoodi activation and the subsequent release of client reports. Before making any judgments about faster or cheaper mainnet transactions, it is essential to observe whether Ethereum protocol changes can be consistently adopted, propagated, and verified across different implementations.
What should you pay attention to?
- Activation on October 26: Confirm that Hoodi reaches epoch 132,352, slot 4,235,264 according to the expected fork rules and the 200 million gas limit.
- Client Consistency: Monitor post-fork releases of execution and consensus layer clients, chain splits, missed duties, and operator updates.
- Builder Timeliness: Measures delays or missing payload disclosures, as well as whether the Payload Timeliness Committee provides consistent judgments.
- Gas and State Behavior: Compare actual block filling, validation times, and application failure rates under the new gas rules.
- Mainnet Notice: Do not treat this as a confirmed launch date until separate announcements regarding the epoch, compatible version, and operational guidelines are published.
Frequently Asked Questions
When is Glamsterdam scheduled to be activated on Hoodi?
The Ethereum Foundation has set the activation time for Hoodi to October 26, 2026, at 17:42:48 UTC, corresponding to epoch 132,352 and slot 4,235,264. The gas limit is also scheduled to increase to 200 million in the same epoch.
Does Glamsterdam have a mainnet date?
No. The October 16 announcement did not confirm the mainnet launch date. A separate announcement will be made once the client team has decided, providing the production schedule.
Has the upgrade been activated on Sepolia?
Yes. The foundation stated that Glamsterdam was activated on Sepolia on October 6. Hoodi is the next planned public testnet, and the activation of Sepolia does not mean that the mainnet has changed.
What is embedded proposer-builder separation?
EIP-7732 incorporates the builder’s initial commitment, subsequent payload disclosure, and proposer payments into Ethereum’s consensus rules, and adds committee checks for timeliness. It changes the handoff process between builders and validators.
What is the purpose of a block-level access list?
EIP-7928 provides verified information about the accounts and storage accessed by a block. Clients can use this to organize state reads and enable partial parallel verification, rather than discovering all dependencies during execution.
Will Ethereum fees decrease after Glamsterdam?
Certain transaction types may benefit from repricing or increased capacity in the future, while state-intensive workloads may become more expensive. Actual mainnet fees depend on demand, usage, and the final operational configuration.
Do ordinary ETH holders need to take any action now?
No action is required. This notice is intended for Hoodi operators and developers. Mainnet users do not need to take any action for this testnet activation; guidance for any future mainnet upgrades will be provided separately.
How do researchers determine whether Hoodi has been successful?
They need more than just an activation timestamp: compatible clients must agree on blocks, builders must disclose payloads on time, and nodes and applications must handle the new rules under meaningful load. This is an educational analysis and does not constitute investment advice.