The useful answer: the October 26 Hoodi activation has been postponed, and that postponement includes the scheduled gas-limit increase to 200M. The same update states that the schedule and activation instructions set out earlier have been superseded. For operators, that means the published plan is no longer a plan to execute against.
The postponement was recorded in an update dated October 22. It does not replace the original announcement with a new activation date; it only marks the earlier material as no longer current.
What was announced, and in what order
The original announcement described the Glamsterdam network upgrade as scheduled for the Hoodi testnet, following its activation on Sepolia on October 6. It gave a specific activation point: Hoodi epoch 132,352, slot 4,235,264, stated as October 26, 2026, 17:42:48 UTC. At the same epoch, the announcement said Hoodi's gas limit would be raised to 200M.
That sequence now matters more than the numbers themselves. The October 22 update says the October 26 activation has been postponed, including the gas-limit increase to 200M, and that the schedule and activation instructions have been superseded. It also points readers to a separate notice titled Glamsterdam on Hoodi Postponed for details and operator guidance.
Nothing in the update supplies a new epoch, slot, timestamp, or gas-limit figure. The earlier values should therefore be read as historical targets, not as pending instructions.
What the upgrade itself changes
Glamsterdam combines the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. Its headlining changes are enshrined proposer-builder separation and block-level access lists, which per the announcement change how blocks are produced and validated to support greater L1 throughput. EIP-7732 brings the separation between block proposers and builders into Ethereum's consensus protocol. The announcement also describes changes to gas pricing intended to better reflect the cost of execution and state growth.
These are described as design intentions and protocol changes. The announcement does not present measured throughput results, nor does it make any claim about fees at the user level. Throughput and finality are separate properties, and nothing in the material connects the two.
Why a postponement changes the checklist
The original guidance was tied to a deadline. Node operators were told they must update both their execution and consensus layer clients before activation. That requirement does not disappear because the date moved; what changes is the moment at which a missed update becomes a live risk.
The postponement also breaks the link between two items that were previously synchronized. The client update and the gas-limit increase to 200M were both attached to the same epoch. With the activation postponed, the pairing can no longer be assumed. An operator plan built around "update clients, then watch the gas limit move at the same moment" no longer reflects the published state of play.
A third change is documentary. When a schedule is superseded rather than amended, old runbooks and internal tickets retain their text but lose their authority. Operators who leave the old activation point in place, even as a placeholder, carry forward a number the announcement no longer endorses.
A worked example of the recheck
Consider a hypothetical operator whose runbook was built from the original announcement. It contains the epoch, slot and timestamp, plus a step to confirm the gas limit reaching 200M at the same epoch.
- The activation entries should be replaced rather than patched, because the announcement marks the instructions as superseded. The operator's own recommendation should be to hold an explicit "awaiting new guidance" state.
- The client-update requirement should stay on the list. It was framed as a must before activation, and the postponement does not withdraw it.
- The gas-limit step should be decoupled from the client step, since the two are no longer tied to a confirmed event.
- The Sepolia activation on October 6 can remain as a reference point, not as a Hoodi timetable.
- Any announcement-derived page should name the October 22 update so readers do not act on the superseded schedule.
Comparison: superseded versus amended
| Element | Original announcement | After the October 22 update |
|---|---|---|
| Activation date | October 26, 2026, 17:42:48 UTC | Postponed; no new date given |
| Gas limit | Raised to 200M at the same epoch | Postponed with the activation |
| Instructions status | Current | Superseded |
| Client updates | Required before activation | Requirement not withdrawn |
| Mainnet date | Not yet decided | No mainnet date announced |
The practical reading is that the upgrade's content did not change on October 22; its timing did. Operators should treat the postponement as a scheduling and instruction-management event, not as a signal about the upgrade's substance.
What the source does not say
- No new Hoodi activation epoch, slot, or timestamp is provided.
- No revised gas-limit target or timing is given.
- No mainnet activation date has been decided.
- Hoodi-compatible client versions are to be added to the release tables as they are confirmed; the update does not confirm any.
- No reason for the postponement is stated in the material provided.
- No claims are made about user-facing fees, finality, or performance outcomes.
Operators should read the separate postponement notice for the details and guidance it is said to contain, and should not infer a replacement schedule from this announcement alone.