Source publication: November 10, 2026, at 10:59 UTC+8. The account below reflects the proposals, benchmarks and scheduling uncertainties reported at that time.
Ethereum’s proposed quantum-resistant architecture would change what a transaction carries, how validators authenticate votes and which cryptographic evidence becomes part of a block. The central data question is whether large signatures and proofs must appear individually on-chain—or whether a block can instead record references backed by an aggregate proof.
An article by @yq_acc, translated into Chinese by AididiaoJP of Foresight News and published by PANews, describes a roadmap built around the latter approach. Its central constraint is delivery: introducing those changes through successive hard forks without breaking assumptions embedded in deployed contracts.
A research target ahead of the official deadline
At Devcon 8, held November 3–6, 2026, in Mumbai, Ethereum Foundation researcher Justin Drake expressed the ambition to complete a quantum-resistant and “post-AI” transition by December 2028. According to the report, that would require three hard forks within 24 months after Glamsterdam.
That ambition was not the Ethereum Foundation’s formal deadline. Its September priorities document targeted quantum resistance across three layers by December 2029 and said the date would remain unchanged until a review with external experts in January 2027.
The draft fork sequence described in the article was:
| Fork | Proposed role |
|---|---|
| Hegotá, or H* | Introduce frame transactions, allowing accounts to choose their authorization scheme; not itself a quantum-resistance fork |
| I* | Introduce leanVM, a minimal proving virtual machine, and quantum-resistant “lean” transactions |
| J* | Add hash-based validator signatures and quantum-resistant data sampling—the proposed “minimum viable quantum resistance” milestone |
| K* and L* | Introduce mandatory execution proofs and the remaining Lean architecture changes |
Three forks in 24 months implies one every eight months. The article lists recent fork intervals of 11, 14 and seven months, with Glamsterdam still unfinished after 11 months. Under the Foundation’s calculation, reaching L* by December 2029 would require an average interval of 7.2 months; at one fork per year, only J* would arrive by that deadline.
Why gas accounting became a compatibility problem
Glamsterdam illustrates why a roadmap cannot be evaluated solely by the readiness of its cryptography.
The upgrade had been running on Sepolia since October 6. Its proposed changes included enshrined proposer-builder separation and block-level access lists, which declare a block’s read and write sets in advance to support parallel execution. But on October 22, it was withdrawn from deployment to a second testnet.
The reported problem involved EIP-8037’s state repricing. It priced new state at 1,530 gas per byte, raising the cost of writing a new storage slot from 22,100 to 110,020 gas and increasing the deployment cost of a 24 kB contract by roughly eightfold.
A separate state-gas reserve would pass gas to called contracts and refund it when calls reverted. ChainSecurity found that this could allow error handlers that previously ran out of gas to finish executing, bypassing common checks intended to prevent malicious interference.
The Foundation identified eight broken invariants—rules expected to remain true—and an AllCoreDevs summary counted 13 affected DeFi projects. Hoodi testing was postponed without a replacement Hoodi or mainnet date. All Core Devs coordinator Nixo wrote that the issue would “very likely push Glamsterdam mainnet into 2027.”
For interpreting execution records, the distinction matters: gas is not just a fee unit. Its allocation can determine which code paths execute. Changing that behavior can change contract outcomes even when deployed bytecode stays the same. The dependency also reaches forward: the report says Hegotá’s frame transactions require EIP-8037.
From signature bytes to proof-backed references
The proposed migration relies heavily on hash-based cryptography. The article cites two motivations: research into lower quantum-computing requirements for attacking elliptic-curve signatures, and concern that AI-assisted mathematical advances could weaken existing schemes before a sufficiently capable quantum computer appears. These are threat assessments, not evidence that Ethereum’s signatures had already been broken.
Hash-based signatures bring a substantial size cost:
- A proposed leanXMSS validator signature is 2,404 bytes, versus 96 bytes for BLS.
- A leanSPHINCS wallet signature is 7,740 bytes.
- Unlike BLS signatures, hash-based signatures cannot simply be added together for aggregation.
The proposed alternative is to prove that signatures were checked. The article reports leanVM performance of approximately 965 signatures per second on a laptop, aggregating 1,500 signatures into a 265 KiB proof that could be verified in 7.4 milliseconds. These are reported benchmarks, not production-network measurements.
At the data layer, the proposed LeanDA design would replace KZG commitments with Merkle commitments and leanVM proofs establishing correct data encoding.
EIP-8288 would move bulky evidence outside the block
EIP-8288, a draft co-authored by Vitalik Buterin and Thomas Coratger in June, proposes signature and proof aggregation within the mempool.
Its transaction structure separates a dependency’s identifier from the underlying cryptographic material:
- A frame transaction declares a dependency through a 96-byte reference containing the scheme, data hash and key hash.
- Nodes check the actual signatures and proofs as transactions arrive.
- Those checks are folded into recursive STARK proofs.
- Builders and inclusion-list participants perform corresponding aggregation for the transactions they select.
- The block header carries one recursive STARK covering the block’s dependencies, which validators verify.
The draft described in the article permits a transaction to declare up to 16 leanSPHINCS signatures and one STARK. STARK dependencies were reserved in the design rather than fully enabled.
The projected cost for an aggregated leanSPHINCS signature was about 33,000 gas: 3,000 for the frame and 30,000 for its share of the block proof. Direct verification was estimated at 150,000–200,000 gas. The specification also targeted roughly 256 KB of builder overhead per aggregation interval, independent of signature count.
These are proposal-level costs and limits. EIP-8288 had no scheduled fork, aggregation keys and dependency hashes remained undecided, and reverted transactions would still incur charges. Its authors acknowledged additional mempool denial-of-service risk and described recursive-proof soundness as widely believed but not yet proved.
Inclusion and proof security remain separate questions
Hegotá’s proposed FOCIL mechanism, EIP-7805, addresses transaction inclusion rather than cryptographic validity. Each slot would have 16 validators 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 enforcement through fork choice.
Large individual signatures and proofs are therefore relevant to both cost and inclusion-list capacity. Aggregation is intended to reduce that burden, but it also makes the security of the proof machinery critical.
The article qualifies Drake’s announcement of end-to-end formal verification for leanVM: the Lean 4 work established properties of instruction semantics and constraints, while the Rust implementation had undergone differential testing. Recursive-proof soundness remained open, and the code was not production-ready.
Likewise, the report says three provers met Ethproofs’ real-time standard on November 8 using four to 16 consumer GPUs, at approximately $0.003–$0.007 per block. Fast proving did not establish that every required security property had been demonstrated. Mandatory execution proofs remained assigned to K* in the draft roadmap.
Faster confirmation is not the same as finality
The article put Ethereum’s existing finality time at approximately 16 minutes. Draft EIP-8453, “Decoupled Consensus,” proposed separating a fast available chain, voted on by a committee of roughly 512 validators, from a finality component run by all validators. Its initial goal was at least a fourfold finality improvement.
Separately, the Fast Confirmation Rule was described as allowing exchanges and bridges to shorten deposit confirmation times to 12–24 seconds. That should not be read as an equivalent claim about protocol finality. The article also cited an exploratory 36-second figure explicitly labeled “not a prediction,” and a longer-term aspiration of one-second blocks with two-second finality.
As of the report’s publication, the key checkpoints were fixes to Glamsterdam’s repricing, a new Hoodi schedule, Hegotá testing of FOCIL alongside frame transactions, and the January 2027 review of the quantum-resistance deadline. The open question was not merely whether the cryptography could work, but whether Ethereum could deploy the dependent changes at the required pace while preserving existing execution behavior.