以太坊核心开发者已暂定将 Glamsterdam 升级于 2026 年 10 月 6 日 13:53 UTC 在 Sepolia 测试网激活，但该安排仍属条件性计划。开发者需先完成 Devnet-11 等私有开发网测试，并确认客户端修复与跨客户端互操作性，才能推进公开测试网分叉。
根据 ACDC #186 会议记录及以太坊协议研究员 Christine D. Kim 的报道，开发者在选择 Sepolia 时间表时，尚未在任何私有开发网络上完成稳定的 Glamsterdam 激活。9 月 3 日 All Core Developers Consensus 会议上，参与者同意为拟议激活采用 Sepolia epoch 351232。Kim 表示，对应时间为 10 月 6 日 13:53 UTC。选定 epoch 为客户端团队、基础设施运营商和应用开发者提供了共同规划目标，但并不代表激活已经最终确定。
开发者可以在下一阶段测试发现重大故障，或客户端团队无法准备可靠版本时推迟分叉。Kim 在 9 月 11 日表示，注意力已转向 Glamsterdam-Devnet-11，预计于 9 月 14 日周一启动。此前计划曾将 Devnet-10 列为下一项主要测试。Hoodi 测试网和以太坊主网均尚未确认激活日期。
测试风险已有先例。Devnet-9 曾出现最终性问题。会议材料显示，该网络包含约 1,000 个验证者节点，是当时按验证者数量计算最大的 Glamsterdam 开发网。最终性需要足够多验证者就链状态达成一致。当测试网络无法最终确认时，开发者必须判断原因来自客户端软件、验证者参与、网络配置，还是不同协议变更之间的交互。
更早的 Glamsterdam 试验已在以太坊架构的共识层和执行层暴露故障。以太坊基金会开发者运营工程师 Stefan Starflinger 报告称，Devnet-8 暴露出一个涉及重复父哈希区块的共识层问题。他在描述测试场景时表示，这可能导致整个网络停止。该问题影响负责区块共识的系统。在执行侧，以太坊基金会研究员 Maria Silva 报告了 EIP-8037 的实现问题。该提案改变以太坊对创建新状态（包括新账户、合约和存储条目）收取 gas 的方式。EIP-8037 通过多维 gas 模型将状态创建成本与普通执行成本分离。其已发布规范称，该设计旨在以太坊提高区块 gas 上限时控制状态增长。该提案仍在同行评审中。发现的问题要求执行客户端修改实现，并推动了规范工作。
Devnet-11 将在 Sepolia 之前测试相关修复。一个稳定的 Devnet-11 将为以太坊客户端团队提供另一个测试 Glamsterdam 组合规范的环境。Layer-2 团队、质押服务商和其他基础设施运营商需要可用的客户端实现，才能安全地针对拟议分叉测试自身系统。客户端多样性使这一过程更复杂：以太坊运行着多个独立开发的执行客户端和共识客户端，升级必须在不同客户端组合中正常工作。即使故障只局限在一个实现中，只要受影响的验证者持有足够权重，仍可能中断测试网络。
ACDC #186 议程记录显示，Lido 和 Optimism 要求在分叉前至少有一个稳定日。议程还将客户端修复和成功互操作性列为 Sepolia 推进前需要确认的事项。Devnet-11 失败或不稳定不会自动取消 10 月 6 日激活；开发者需要评估原因和修复所需时间。若出现严重问题，他们可能在 All Core Developers 会议上重新考虑该日期。
Hoodi 和主网日期取决于测试结果。由于 Sepolia 仍属条件性安排，开发者拒绝为 Hoodi 设定 Glamsterdam 时间。Hoodi 预计将作为第二个公开测试网阶段，为质押运营商和协议团队提供更接近主网条件的环境。Teku 开发者 Enrico del Fante 支持在确定 Hoodi 日期前继续等待。他在 ACDC #186 会议上提到近期 Devnet-9 问题，并赞成在 Sepolia 决定后留出更多测试时间。12 月主网激活仍是可能目标，而非已确认启动窗口。将 Sepolia 安排在 10 月初，为下一阶段公开测试网和客户端发布准备保留了足够日程时间，前提是测试没有出现长时间延迟。开发者尚未公布主网 epoch、激活时间戳或最终客户端发布时间表，也没有宣布决定 10 月 6 日是否合适的正式截止期限。近期程序性事件是计划于 9 月 14 日启动的 Devnet-11。客户端团队将检查最终性、跨客户端行为以及早前测试后引入的修复，再决定 Sepolia 能否按当前时间表推进。