Historical-source report: November 10, 2026, at 10:59 UTC+8. The dates, development status and forward-looking targets below reflect the supplied article’s reporting context.
Ethereum’s proposed transition to post-quantum cryptography faces a scheduling challenge as much as a cryptographic one. According to the source article, Ethereum Foundation researcher Justin Drake used Devcon 8 to outline an ambition to complete a post-quantum and “post-AI” transition by December 2028—a year ahead of the foundation’s formal deadline.
For validators, the proposed changes would reach well beyond replacing a signing key. They would introduce new signature-verification machinery, alter data-availability commitments and potentially separate fast chain confirmation from finality. These are roadmap proposals and research directions, not completed mainnet upgrades.
An accelerated ambition, not a revised official deadline
Devcon 8 took place at Mumbai’s Jio World Centre on November 3–6, 2026. The article reports that Drake’s opening-day target would require three hard forks within 24 months after Glamsterdam: roughly one every eight months.
The Ethereum Foundation’s September priorities document instead committed to post-quantum protection across three layers by December 2029. That date was to remain unchanged until a review with external experts in January 2027. The distinction matters: December 2028 was the research ambition described at Devcon, not an adopted replacement for the official deadline.
The draft roadmap placed the changes in this sequence:
- Hegotá, planned for 2027: introduce frame transactions, allowing accounts to define their authorization schemes. This would provide a route away from ECDSA, but Hegotá itself was not described as the post-quantum fork.
- I*: introduce leanVM, a minimal proving virtual machine, and post-quantum “lean” transactions.
- J*: introduce hash-based validator signatures and post-quantum data sampling, reaching what the foundation called a “minimum viable post-quantum” milestone.
- K* and L*: introduce mandatory execution proofs and the remaining Lean architecture changes.
The later fork labels were placeholders. According to the article, reaching L* by December 2029 would require an average interval of 7.2 months between forks; at a 12-month cadence, only J* would arrive by that deadline.
Glamsterdam exposes the compatibility problem
The immediate obstacle was Glamsterdam. It had been running on Sepolia since October 6, but its rollout to a second testnet was withdrawn on October 22. Hoodi’s launch was postponed, with no replacement Hoodi or mainnet date available in the report.
Glamsterdam’s core changes included enshrined proposer-builder separation, bringing builder bids into the protocol and moving execution off the slot’s critical path, and block-level access lists, declaring reads and writes in advance to support parallel execution.
The reported disruption came from state repricing under EIP-8037. The proposal priced new state at 1,530 gas per byte. Creating a new storage slot would rise from 22,100 to 110,020 gas, while deploying a 24 kB contract would cost approximately eight times as much.
A separate state-gas reserve was intended to accommodate these costs. ChainSecurity found that its behavior could allow error-handling code to finish where it previously would have exhausted its gas, bypassing common anti-griefing checks. The foundation identified eight broken invariants—rules expected always to hold—and an AllCoreDevs summary counted 13 affected DeFi projects.
All Core Devs coordinator Nixo wrote that this would “very likely push Glamsterdam mainnet into 2027,” according to the article.
This matters to the post-quantum sequence because Hegotá’s frame transactions listed EIP-8037 as a requirement. A compatibility problem in one fork could therefore delay the foundation needed by later cryptographic changes.
What would change for validators?
The proposed validator migration starts with an additional key rather than an immediate replacement. Under draft EIP-8450, validators would register a dormant hash-based key alongside their existing key.
The size difference is substantial: the article gives a leanXMSS signature size of 2,404 bytes, compared with 96 bytes for BLS. BLS signatures can be combined algebraically; hash-based signatures cannot be aggregated in the same way.
The proposed substitute is proof-based aggregation:
- Validators produce their signatures.
- An aggregator checks those signatures.
- The aggregator generates a proof that the checks were performed correctly.
- Other participants verify the proof rather than checking every signature individually.
The article reports that leanVM aggregated approximately 965 signatures per second on a laptop. A batch of 1,500 signatures produced a 265 KiB proof that could be verified in 7.4 milliseconds. These were reported development results, not evidence of live-network deployment.
The proposed data layer would also change: LeanDA would replace KZG commitments with Merkle commitments and leanVM proofs showing that data had been encoded correctly.
There were important assurance gaps. Although Drake described leanVM as end-to-end formally verified, the article distinguishes the verified instruction semantics and constraint soundness in Lean 4 from the Rust implementation, which had undergone differential testing. Recursive-proof soundness remained an open question, and the code was not production-ready.
Moving signature work into the mempool
Draft EIP-8288, co-authored by Vitalik Buterin and Thomas Coratger, proposed aggregating signatures and proofs before transactions enter a block.
Its purpose was to avoid putting large cryptographic objects directly on-chain. Transactions would declare dependencies through 96-byte references identifying the scheme, data hash and key hash. Nodes would check the underlying signatures and proofs as transactions arrived, then aggregate that work into recursive STARK proofs. Builders and FOCIL inclusion-list participants would perform corresponding checks for the transactions they included.
The block header would carry one recursive STARK covering the block’s dependencies, leaving validators to verify that proof.
For wallets, the article reported a 7,740-byte leanSPHINCS signature. With aggregation, its estimated cost was approximately 33,000 gas, versus 150,000–200,000 gas for direct verification.
Those figures describe a proposal, not an available mainnet fee schedule. EIP-8288 remained a draft, with aggregation keys and dependency hashes unresolved. Support for STARK dependencies was reserved rather than activated. The authors also acknowledged additional mempool denial-of-service risk, and recursive-proof soundness had not been proven. No deployment schedule was given.
Inclusion and finality are separate changes
Hegotá’s proposed FOCIL mechanism, EIP-7805, addressed transaction inclusion. Each slot, 16 validators would publish inclusion lists containing up to 8 KiB of mempool transactions each. The following block would have to include those transactions unless they were invalid or the block was full, with attesters enforcing the requirement through fork choice.
A separate draft, EIP-8453, addressed finality. The article described Ethereum’s finality time as approximately 16 minutes. Its “decoupled consensus” design would separate a fast, available chain voted on by a committee of approximately 512 validators from a finality component run by all validators. The initial objective was at least a fourfold improvement in finality speed.
More ambitious figures remained exploratory: finality.watch’s 36-second scenario was explicitly labeled “not a prediction.” It should not be read as a scheduled network capability.
The milestones that remained unresolved
From the article’s November 10 reporting date, the next checkpoints included discussions of EIP-8037/8038 fixes at ACDC #191 on November 12 and ACDE #249 on November 19, a revised Hoodi schedule, and the January 2027 review of the post-quantum deadline.
Other open questions included whether Hegotá development networks could run FOCIL and frame transactions together, which post-quantum key registry would be selected and for which fork, and whether leanVM’s proof system could receive the required soundness guarantees.
The central dependency was clear: a post-quantum design needed not only workable cryptography, but a sequence of compatible, securely implemented upgrades. The eight-month fork cadence remained an ambition to demonstrate, not an established delivery schedule.
Original source: PANews — “Ethereum’s 2028 test: the post-quantum roadmap meets release bottlenecks”, published November 10, 2026, at 10:59 UTC+8. Written by @yq_acc; Chinese translation credited to AididiaoJP, Foresight News.