Ethereum developers gave Glamsterdam’s first devnet a conditional mid-April target

Ethereum core developers used their March 19, 2026 consensus-layer meeting to place a conditional mid-April target on Glamsterdam Devnet 0, the first coordinated development network for Ethereum’s next major upgrade. The target depended on resolving an outstanding Payload Timeliness Committee, or PTC, specification question by March 24. It was a dated engineering checkpoint—not a mainnet activation schedule, completed release or guarantee that testing would begin on time.

What the March 19 record establishes

Ethereum’s public project-management repository scheduled All Core Developers Consensus call 176 for 14:00 UTC on March 19. Its agenda centered on Glamsterdam devnet readiness, unresolved specifications for enshrined proposer-builder separation, or ePBS, PTC handling, EIP-4788 behavior, the Engine API and early planning for the subsequent Hegotá upgrade. Ethereum also published the official recording under the same meeting number and date.

A contemporaneous technical recap reported that developers were targeting the middle of April for Devnet 0, before broader interoperability testing. It identified the PTC fix as the remaining hard-fork requirement blocking that step and recorded March 24 as the decision deadline. That conditional language is essential: the meeting produced a working target around an unresolved dependency, not a completed protocol milestone.

Why the PTC question mattered

Glamsterdam’s consensus-layer work included ePBS, a design intended to bring proposer-builder separation into Ethereum’s protocol. That architecture changes how block-building responsibilities, execution payloads and consensus duties interact. PTC-related rules therefore had to be predictable enough for independently developed clients to reach the same result under the same network conditions.

The underlying specification discussion shows why the issue was not merely administrative. Developers were comparing approaches for retaining committee information in beacon state, including a proposal that kept two committees and added about 8 kilobytes per state. Repository discussion also examined the relationship between lookahead, lookbehind, state size and specification simplicity. Those alternatives represented implementation trade-offs under review, not finalized mainnet parameters on March 19.

A test target with visible constraints

The same-day recap described Prysm, Lighthouse and Lodestar as operational in the early test environment while reporting unresolved problems for Nimbus, Teku and Grandine. It also identified complications involving empty execution payloads, possible backfilling under EIP-4788, parent-block reorganizations and proposed SSZ encoding for communication between Ethereum’s consensus and execution clients.

These details explain why a devnet matters. A development network lets multiple client teams test whether separate implementations can follow a shared draft specification, remain synchronized and recover from edge cases. Success on one devnet does not prove mainnet readiness. Failures can instead reveal ambiguous specifications, incompatible assumptions or performance problems before public testnets and production activation are considered.

What was—and was not—decided

The verified development on March 19 was a conditional coordination decision: aim for Devnet 0 in mid-April, provided the PTC specification issue could be resolved on the stated timetable. The public record does not establish that Glamsterdam activated, that every client was interoperable or that ePBS design work was complete on that date.

Nor did the call establish a token-price consequence. Protocol-development meetings can be consequential without producing an immediate market event. Their significance lies in making dependencies, implementation disagreements and test criteria visible before code is placed on a live network. The next evidentiary milestones after March 19 were the PTC decision, merged specifications, working multi-client devnets and subsequent formal scheduling; none should be projected backward into this dated reconstruction.