Ethereum developers have scheduled the Glamsterdam upgrade for Hoodi on October 26 after its Sepolia activation. The next test will examine block production, state access and gas changes together before client teams choose a mainnet date.
Summary
- Glamsterdam activated on Sepolia on October 6 and is scheduled for Hoodi on October 26 at 17:42:48 UTC.
- Hoodi’s gas limit is set to rise to 200 million at the same epoch, according to the Ethereum Foundation.
- EIP 7732 brings the proposer and builder exchange into the consensus protocol, with new payload timeliness duties.
- EIP 7928 supplies block access lists intended to let clients read and validate more work in parallel.
- Mainnet has no activation date, and operators need compatible execution and consensus clients before a network fork.
Ethereum’s Glamsterdam upgrade is due to activate on the Hoodi testnet at epoch 132,352 on October 26, with no mainnet date set. The Ethereum Foundation’s October 16 announcement followed a Sepolia activation on October 6 and set the Hoodi slot at 4,235,264. Client teams still have to confirm compatible releases across the execution and consensus layers. The published schedule establishes the next trial, not a launch date for changes to Ethereum’s live economy.
— crypto.news (@cryptodotnews) October 4, 2026JUST IN: Ethereum’s Glamsterdam upgrade will activate on Sepolia on Oct. 6
The testnet deployment will mark the next major step toward bringing Glamsterdam closer to Ethereum’s mainnet. pic.twitter.com/uW9703RGHC
Glamsterdam combines several kinds of work that are easy to collapse into a slogan about speed. It changes how a proposer and a builder exchange a block payload, supplies a block-level list of state accesses, and reprices operations that create or read chain state. It also adjusts other execution and validator rules. A testnet can show whether the pieces work together across different clients and applications; it cannot by itself prove that the mainnet will run a higher gas limit safely under real financial load.
October 26 is a testnet commitment
The announced Hoodi activation time is 17:42:48 UTC on October 26, at epoch 132,352 and slot 4,235,264. The Foundation says Hoodi’s gas limit will rise to 200 million at that epoch, matching Sepolia. The mainnet entry in the published activation table remains undecided. A reader should not convert the testnet time into an Ethereum mainnet countdown or assume that the same gas limit will become a mainnet setting immediately.
Before activation, Hoodi operators need the versions of both execution and consensus clients that explicitly support this fork. A validator also runs a validator client alongside its beacon node. The Foundation lists confirmed releases for several teams and says remaining entries will be updated. The absence of a version in a particular table is not proof that the team has abandoned the fork; it means an operator should wait for an explicit compatible release rather than guessing from a version number.
A network upgrade requires node operators to opt in by updating software. Nodes that continue to apply the prior rules cannot follow the upgraded chain after the fork. The next question is therefore not merely whether the clock reaches the scheduled slot. It is whether multiple independent implementations agree on the resulting chain, accept the same blocks and recover smoothly from realistic edge cases. A visible testnet success should be assessed in that operational context.
Crypto.news previously covered the Sepolia schedule before the first announced public activation. Sepolia has now crossed that milestone; Hoodi tests a separate environment and a higher published gas limit. The Foundation’s mainnet notice, client-release guidance and post-fork observations are the authoritative sequence to follow after October 26.
A new handoff between block builders and proposers
Ethereum validators propose blocks, but specialized builders can assemble execution payloads. Today much of the exchange between those actors runs through infrastructure outside the core consensus protocol. EIP 7732, called enshrined proposer-builder separation, moves the commitment, reveal and proposer payment logic into protocol rules. The proposer commits to a builder’s payload; the builder reveals it later under prescribed conditions.
The EIP 7732 specification describes new structures and timing around this exchange. The objective is to reduce reliance on trusted middleware for the basic builder-proposer payment and handoff. It does not promise the end of all relays or private arrangements. The Ethereum roadmap’s Glamsterdam explanation notes that participants can still choose outside services for functions beyond the new protocol mechanism.
A payload timeliness committee adds a duty: members attest whether the builder’s payload was revealed on time and its corresponding blob data available. Consensus validation and execution validation have different moments. The arrangement is intended to give validators more time to verify the heavy execution work while preserving a timely consensus process. Builder operators must satisfy the new interfaces and deadlines; validators must recognize when a committed payload failed to arrive.
Failure cases matter as much as an ordinary completed block. A builder might withhold a payload, reveal it late, or present data that different clients process inconsistently. The protocol must define the result without leaving validators guessing which chain to extend. Hoodi offers a public environment for client teams to exercise those paths and for operators to observe whether builder and validator software follows the same rules.
An enshrined handoff also raises an economic question. Removing trust from the core payment step may lower one barrier for builders, but it does not show that block construction becomes competitive. Builder concentration, access to order flow and the cost of infrastructure require measurements after deployment. A new protocol can formalize roles without guaranteeing that the market performing those roles diversifies.
Block access lists and the work a node must do
EIP 7928 introduces a record of accounts and storage locations accessed during a block, along with the post-transaction state changes. Validators currently need to discover some dependencies while processing a block. With a verified list, clients can schedule reads from disk and some validation work in parallel where operations do not conflict. The list is a protocol object, not a prediction posted by an outside data vendor.
The EIP 7928 proposal defines the data and checks needed for block-level access lists. The intended benefit is practical: execution cannot scale sustainably if each extra unit of block gas forces every node through an equally long serial path. Access information can shorten the slowest part of validation, provided builders create accurate lists and clients reject inconsistent ones.
A list adds data of its own. Larger blocks, complex state touches and network propagation can offset gains if implementations are inefficient. Parallel reads are not the same as every transaction executing independently; two calls that touch the same storage location still have an order. Nor does a testnet gas-limit change automatically give ordinary users a specific percentage reduction in fees. Fees depend on demand for space as well as the capacity supplied.
The Foundation frames block access lists and the new builder handoff together as the basis for more L1 throughput while keeping validation feasible. A node with limited hardware is a useful test of that claim. If only high-end operators can keep up with block propagation or state access at greater load, an apparent capacity gain may come with pressure on the range of people able to validate the chain. Public client performance and diversity after Hoodi matter more than a gas-limit number alone.
Crypto.news examined the access-list tradeoff in prior coverage of the upgrade’s design. The specific feature is an input to validation, while a target like 200 million gas is a setting for a test network. Reporting them as separate variables allows a clearer account of which change actually improved performance.
Gas prices change for different kinds of work
Glamsterdam reprices operations as well as reorganizing blocks. EIP 8037 raises and separately meters the cost of creating state; EIP 8038 updates state-access charges. Other included proposals modify intrinsic transaction gas, calldata costs, access lists and block gas accounting. A transfer, a complex contract deployment and a storage-heavy application do not all face the same direction or size of cost change.
The Foundation’s repricing impact guide says replaying historical mainnet transactions under the proposed schedule found a small group of contracts relying on gas assumptions that may break or degrade. It says most flagged cases can be fixed with higher gas limits and the large majority of contracts were unaffected in that analysis. Historical replays identify candidates; they cannot cover every future call or application state.
Developers should pay particular attention to fixed gas stipends, hardcoded limits and code that makes decisions from the remaining gas. A transaction that passed previously could fail because the reweighted work exceeds its allowance, even if the underlying logic remains correct. An application estimating fees must account for the new rules to prevent preventable failed transactions. The Foundation says it has begun contacting the most affected builders.
An earlier report on wallet and gas tools highlighted a precise case: an ordinary ETH transfer to an existing account keeps the familiar 21,000-gas figure, while creating a new account adds a state charge. The roadmap suggests some ordinary actions could become cheaper while state creation becomes more costly. An average network fee observed after a future mainnet launch would not isolate the rule’s effect without comparing activity, block demand and base fees. A lower intrinsic gas requirement can help one transaction type, while a busier chain fills the newly available capacity. Reporting a blanket fee cut in advance would ignore the distinction.
The scheduled EIP 7773 meta proposal lists 18 principal EIPs in the Foundation’s Hoodi announcement. Some changes are relatively visible to application builders, such as ETH transfer logs, a slot-number opcode and a higher maximum contract size. Others alter validator churn or exclude slashed validators from proposing. The size of the bundle increases the value of integrated testing: a client might implement each feature individually but still disagree with peers when several affect one block.
Hoodi’s 200 million gas limit is not a throughput promise
A block gas limit is an upper bound on the execution resources a block can consume under the chosen schedule. Doubling a numerical limit would not necessarily double payment throughput or halve the price of a contract call. The gas schedule itself changes in Glamsterdam, and the mix of transactions matters. A transaction that uses more gas under new accounting can consume more of the cap even if its application behavior is unchanged.
Coverage of Sepolia’s 200 million gas test established the earlier testnet setting. The October 26 Hoodi change will set the limit to 200 million at the fork epoch. Such a stress setting can surface propagation delays, slow execution, state access bottlenecks and clients that cannot process the worst blocks at pace. A testnet’s economic demand is not the same as mainnet’s. It may require purpose-built transactions to exercise the high end of the permitted limit; otherwise a large configured cap could sit largely unused.
For comparison, the most revealing measurement would include the portion of the limit actually filled, time taken by different clients to process the payload, missing or late builder revelations, attestation performance and any chain disagreements. A single successful block below the cap does not establish that nodes can regularly handle blocks approaching it. Conversely, a testnet failure may identify a fixable implementation problem rather than invalidate the scaling design.
The Foundation has not set the mainnet gas limit in this Hoodi notice. Validators on Ethereum can express gas-limit preferences under network rules; a testnet schedule and a mainnet operating choice are separate decisions. Reporting on the upgrade should identify which number belongs to which network and when it is in force.
Why a testnet result can mislead
A public testnet tests protocol agreement under an observable network with developers, validators and people deliberately probing failure cases. It is valuable because separate client implementations must accept the same transition at the same slot. It is still an imperfect stand-in for mainnet. Test ether has no comparable market value, so a malicious participant may take risks that would be expensive on the live chain. Some applications do not deploy the same contracts or generate the same traffic mix on both networks.
A clean activation could conceal an uneventful workload. A 200 million gas ceiling reveals little if most Hoodi blocks use far less. Client teams can create or solicit demanding workloads, but a synthetic stress transaction may touch state in a pattern unlike a live exchange, lending market or rollup settlement. The relevant report after the fork should show the distribution of block sizes, execution time and missed duties, with the workload described. A maximum observed value without a sample size can flatter a system.
Multiple clients are another variable. A network could keep producing blocks because the dominant software works while a less common implementation falls behind. Ethereum’s resilience depends partly on independent teams reaching the same result. Hoodi observations should distinguish client versions and error reports rather than treat one chain head as sufficient proof of compatibility. If clients disagree about an access list or builder payload, the cause must be identified before scheduling a production fork.
Testnet users may also intentionally behave badly. The warning about builder withholding arose because a builder could use inexpensive testnet assets to win commitments and then fail to reveal payloads repeatedly. Under the new rules, a network should continue to decide payload timeliness consistently. Such attacks are a useful trial of the mechanism rather than a reason to judge the upgrade solely by the percentage of ordinary blocks that complete. The question is whether failures are contained and clients agree on the prescribed recovery path.
Finally, deployment readiness includes infrastructure outside the consensus specifications. RPC providers, block explorers, builders, staking services and contract monitoring systems need to interpret new logs, access-list information and deadlines. A testnet node may remain synchronized while a wallet quotes an unsafe gas limit. Mainnet readiness is therefore a set of testable claims by different operators, not a single yes-or-no result from the foundation’s activation table.
Who must change software, and who does not
A Hoodi validator has the immediate operational deadline. Its execution client, beacon node and validator client need compatible releases and any builder tooling must understand the new handoff. A non-staking Hoodi node still needs both execution and consensus clients. Builders and relays should examine their own interfaces, even if they are not the ones attesting to blocks. Misconfigured software can miss duties or stop following the upgraded testnet.
An ordinary mainnet ETH holder has no action to take because of the Hoodi announcement. The Foundation explicitly says a separate notice will cover mainnet activation. Wallet and application teams can use the intervening testnet period to exercise gas estimation, logs, new opcodes and contract edge cases. None of that requires a user to move coins to a testnet or sign a purported upgrade transaction.
Developer concerns about builder abuse during testing remain relevant. A credible test of ePBS needs honest and faulty builder behavior, along with diverse clients, rather than only an idealized sequence of blocks. Security work includes a bug bounty for the specifications and eligible client implementations as releases are added to the Foundation’s tables.
The public testnet also imposes a coordination cost. Client teams publish binaries, operators update, tooling providers adapt and application teams retest. A mainnet date chosen before compatible clients and infrastructure are ready would create avoidable risk. A long delay after a healthy Hoodi fork could mean remaining work in less visible components; the activation alone cannot explain the entire decision schedule.
The price and rollup claims need their own evidence
An upgrade can improve a network’s technical capacity without causing a measurable rise in ETH demand on the day it activates. Holders do not receive an automatic distribution for a successful testnet fork. Builders may invest in equipment, validators may update software and applications may adjust gas settings; those are operating changes rather than a purchase order for the token. Macro conditions and positioning can dominate market prices over the same week.
Layer 2 networks are another place where expectations can run ahead of measurements. The new block handoff is designed to give validation more time and support a path toward greater data availability. A rollup’s costs, however, depend on the price and supply of the data capacity it uses, its batching choices and demand from its own users. The Hoodi activation does not disclose the future mainnet price of a blob or establish that every rollup passes savings through to customers.
Likewise, a higher L1 gas limit could admit more transactions, but the user fee depends on how much of that space others want. A period of low demand might make fees appear cheap regardless of the upgrade. A burst of trading could fill more capacity and keep the base fee high. A fair comparison would examine similar workloads before and after a production change, adjusted for usage. Testnet fees paid in valueless assets cannot stand in for that analysis.
Developers have reason to care even without a near-term price prediction. A contract whose gas estimate fails can strand a transaction; a validator whose client cannot follow the fork can miss rewards; a builder that misses its reveal window may lose a block opportunity. Those are consequences that can be measured around the test. A claim that ETH will rise or that Ethereum fees will be cut by a fixed percentage cannot be derived from an activation date or gas-limit configuration.
What would count as progress toward mainnet?
The strongest favorable case is that Hoodi activates at the specified slot, independent clients stay in agreement, payload timing works under stress, and access lists help keep execution practical at heavier gas usage. Contracts flagged by repricing tests are updated or given safe operating limits. Teams then publish a dated mainnet plan and compatible client releases. That sequence would turn an engineering design into an actionable production schedule.
The opposing case deserves equal attention. Payload duties could prove difficult for validators or builders to coordinate; large access lists could burden propagation; repricing could expose more broken assumptions than historic replays suggested. A testnet might look stable under light demand but reveal weaknesses when participants deliberately approach the new limit. Those are reasons to extend testing, revise an EIP or change a mainnet configuration rather than assign an unsupported calendar date.
No official mainnet activation date appears in the Foundation’s October 16 announcement. The roadmap’s broad Q4 expectation is a planning window, not an adopted fork slot. The next verifiable development is the Hoodi activation and the client reports that follow it. Ethereum’s protocol changes can be judged by whether the new blocks are agreed, propagated and validated across implementations before claims about faster or cheaper mainnet transactions are made.
What to watch
- October 26 activation: Verify Hoodi reaches epoch 132,352 and slot 4,235,264 with the intended fork rules and 200 million gas limit.
- Client agreement: Follow execution and consensus client releases, chain splits, missed duties and operator updates after the fork.
- Builder timeliness: Measure late or missing payload reveals and whether the payload timeliness committee reaches consistent judgments.
- Gas and state behavior: Compare actual block fill, validation times and application failures under the new gas schedule.
- Mainnet notice: Wait for a separately announced epoch, compatible releases and operational guidance before treating a launch date as set.
FAQ
When is Glamsterdam scheduled for Hoodi?
The Ethereum Foundation sets Hoodi activation for October 26, 2026, at 17:42:48 UTC, epoch 132,352 and slot 4,235,264. The gas limit is scheduled to rise to 200 million at the same epoch.
Is there a Glamsterdam mainnet date?
No. The October 16 announcement leaves the mainnet time undecided. A separate announcement will give the production schedule once client teams decide it.
Did the upgrade already activate on Sepolia?
Yes. The Foundation says Sepolia activated Glamsterdam on October 6. Hoodi is the next scheduled public testnet, and a Sepolia activation does not mean mainnet has changed.
What is enshrined proposer-builder separation?
EIP 7732 places the basic builder commitment, later payload reveal and proposer payment inside Ethereum’s consensus rules, with committee checks on timeliness. It changes the handoff between builders and validators.
What do block-level access lists do?
EIP 7928 provides verified information about accounts and storage touched by a block. Clients can use it to organize state reads and some validation work in parallel rather than discovering every dependency as they execute.
Will Ethereum fees fall after Glamsterdam?
Some transaction types may benefit from repricing or eventual added capacity, while state-intensive work can become more expensive. Actual mainnet fees will depend on demand, usage and the final operating configuration.
Do ordinary ETH holders need to act now?
No. The notice concerns Hoodi operators and developers. Mainnet users need no action for this testnet activation, and any future mainnet upgrade will receive separate guidance.
How will researchers know Hoodi worked?
They need more than an activation timestamp: compatible clients must agree on blocks, builders must reveal payloads on time, and nodes and applications must handle the new rules under meaningful load. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 19, 2026.