Ethereum Foundation's PQ Team and the M Question: Is the Migration Plan Ambitious Enough?

blockchain_brian · February 18, 2026, 7:19pm

The EF Finally Takes Quantum Seriously – But Is $2M Enough?

In January 2026, the Ethereum Foundation did something that should have happened years ago: they formed a dedicated post-quantum cryptography team, appointed Thomas Coratger to lead it, and committed $2 million in research prizes. They also elevated post-quantum security to one of the foundation’s top strategic priorities.

As someone who has been contributing to the Ethereum ecosystem for nine years and has watched how the EF allocates resources, I want to provide an honest assessment of what this means, what the challenges are, and where I think the current approach falls short.

What the EF’s PQ Team Is Actually Building

Based on the public announcements and my conversations with people close to the project, here is what we know:

leanVM: The Cornerstone of PQ Ethereum

The EF is developing leanVM, described as a minimalist zero-knowledge proof virtual machine optimized for quantum-resistant hash-based signatures. This is not a replacement for the EVM – it is a specialized execution environment for verifying post-quantum signatures efficiently.

The architecture appears to work like this:

Users sign transactions with PQ signatures (likely ML-DSA or SLH-DSA)
A ZK proof is generated that attests to the validity of the PQ signature
The ZK proof is verified on-chain using hash-based verification (STARK-friendly)
This keeps the on-chain verification cost manageable despite the larger PQ signatures

This is clever engineering because it addresses the biggest practical concern – on-chain verification cost – without requiring every node to implement native PQ signature verification. The ZK proof acts as a compression layer.

PQ Consensus Test Networks

Multiple independent teams are running post-quantum consensus test networks with weekly coordination calls. This is significant because it means the EF is not treating this as a single-team effort. Having multiple implementations being tested in parallel reduces the risk of a single point of failure in the migration.

The $1 Million Research Prize

The EF added a $1 million research prize specifically for improvements to hash-based cryptography and core protocol components. This is a smart use of incentives – the academic cryptography community has the expertise but often lacks blockchain-specific context. A prize can attract attention from researchers who might not otherwise engage with blockchain problems.

The Migration Challenge: Why This Is Harder Than the Merge

I keep hearing people compare the PQ transition to the Merge (Ethereum’s switch from Proof of Work to Proof of Stake). Having been involved in the Merge process, I can tell you the PQ migration is significantly harder for several reasons:

1. The Merge Did Not Change the Transaction Format

When Ethereum switched to PoS, the transaction format remained the same. Users did not need to do anything. Their wallets worked the same way, their contracts worked the same way, their addresses did not change.

The PQ migration requires changing the fundamental transaction signature scheme. Every wallet needs to support new key generation, new signing, and new address formats. Every user needs to actively migrate their funds to PQ-safe addresses. This is a coordination problem that the Merge explicitly avoided.

2. There Is No “Flag Day” for PQ Migration

The Merge had a clear flag day: the terminal total difficulty at which PoS activated. The PQ migration cannot work this way because:

Not all users can migrate simultaneously (many keys are in cold storage, lost hardware, or controlled by contracts with timelocks)
Both ECDSA and PQ signatures need to coexist for an extended period
The migration needs to be gradual to avoid network disruption

This means maintaining two parallel signature verification paths for years, which doubles the attack surface and increases client complexity.

3. Smart Contracts Cannot Self-Migrate

The Merge did not require changes to deployed smart contracts. The PQ migration will. Any contract that verifies signatures – multisig wallets, governance contracts, meta-transaction relayers, permit functions – needs to be updated to support PQ signatures.

For upgradeable contracts (proxies), this is manageable but still requires governance votes and careful testing. For immutable contracts, the funds need to be migrated to new PQ-safe versions. Some of those immutable contracts hold billions of dollars and have complex withdrawal conditions that may take months or years to unwind.

4. Cross-Chain Dependencies

Ethereum does not exist in isolation. Bridges, L2 sequencers, oracle networks, and cross-chain messaging protocols all depend on Ethereum’s signature scheme. A PQ migration on Ethereum needs to be coordinated with every system that interacts with Ethereum signatures.

If Ethereum migrates to ML-DSA but a bridge contract on another chain only supports ECDSA, that bridge breaks. The coordination cost across the multi-chain ecosystem is enormous.

Is $2M Enough?

Let me put the EF’s investment in perspective:

Entity	Annual Quantum Computing R&D
Google	~$1-2 billion
IBM	~$500 million-$1 billion
China (state programs)	~$15 billion (estimated)
US (CHIPS Act quantum allocation)	~$800 million
Ethereum Foundation	$2 million

The EF’s $2M is roughly 0.01% of what China alone is investing in quantum computing. Now, the EF does not need to build a quantum computer – they need to defend against one. But even the defensive side requires significant investment in cryptographic research, implementation, testing, and deployment.

I think $2M is a reasonable starting allocation for a research team, but if this stays at $2M for another year, it will be woefully inadequate. The real costs come when the migration enters the implementation and deployment phase, which will require:

Client team engineering time (4 major client teams, 2-3 FTEs each for 2-3 years)
Security audits of new cryptographic implementations
Testnet infrastructure
Developer tooling and documentation
User education and wallet migration support

A realistic total budget for the full PQ migration is probably $50-100M over 5 years. The EF has the resources – they hold billions in ETH and stablecoins. The question is whether they will allocate appropriately before it is too late.

What I Want to See Next

A concrete EIP for PQ-safe transaction types. Not an abstract research direction, but a specific proposal with a timeline for inclusion in a hard fork. Even if the EIP evolves significantly during development, having a concrete specification focuses engineering effort.
Dedicated PQ tracks in Glamsterdam and Hegota planning. If PQ migration is truly a top strategic priority, it needs dedicated hard fork consideration, not just a research team operating in parallel.
Cross-client PQ interoperability testing. The weekly coordination calls are a good start, but we need public testnets where anyone can test PQ transactions and provide feedback.
L2 coordination. The Ethereum Foundation should be proactively engaging with rollup teams about PQ migration planning. If L1 migrates but L2s do not, the security model breaks.

The Ethereum developer community has never failed to ship when there is sufficient urgency and coordination. But right now, I do not see the urgency level matching the threat level. That needs to change.

I would welcome input from other EF grantees and core contributors. If you are involved in PQ-related work, please share what you are seeing on the ground.

security_sophia · February 18, 2026, 7:21pm

Brian, your comparison to the Merge is extremely well-articulated, and I agree with your assessment that the PQ migration is harder on every dimension. But I want to push back on one point and amplify another.

The $50-100M Estimate Is Conservative

Your cost estimate of $50-100M over 5 years for the full PQ migration is reasonable for the Ethereum L1 alone. But it does not account for the ecosystem-wide cost:

Wallet providers (MetaMask, Ledger, Trezor, etc.) each need to implement PQ key generation, storage, and signing. Hardware wallets need new firmware and potentially new hardware for the larger key sizes. Estimate: $5-10M per major wallet provider.
L2 teams (Arbitrum, Optimism, Base, zkSync, Starknet, etc.) each need independent PQ migrations. Estimate: $5-20M per L2.
DeFi protocols (Aave, Uniswap, MakerDAO, etc.) need to audit, update, and redeploy contracts. Estimate: $1-5M per major protocol.
Oracle networks (Chainlink, Pyth, etc.) need PQ-safe data attestation. Estimate: $5-15M per network.
Bridge protocols (Wormhole, LayerZero, etc.) need cross-chain PQ coordination. Estimate: $3-10M per bridge.

Total ecosystem cost: $200M-$500M is a more realistic range. This is still a fraction of the value at risk (hundreds of billions), so it is clearly worth the investment. But the coordination required to mobilize this level of spending across independent, often competing entities is daunting.

The Immutable Contract Problem Is the Real Killer

I want to emphasize something you mentioned that I think deserves more attention: immutable smart contracts.

The top 100 DeFi protocols by TVL collectively hold over $100 billion. A significant portion of that value is in contracts that cannot be upgraded. Some examples:

Uniswap V2 and V3 core contracts: Immutable by design. The pool contracts verify signatures for permit functions but cannot be upgraded to support PQ signatures.
Early Aave lending pools: Some deployed before proxy patterns were standard.
Wrapped token contracts: WETH and other wrapper contracts that hold billions are often immutable.

For these contracts, the only migration path is to deploy new PQ-safe versions and convince users and liquidity providers to migrate their assets. This is not just an engineering problem – it is a game theory problem. Who migrates first? What happens to liquidity fragmentation? How do you handle the LP incentive structures during transition?

I strongly support your call for a concrete EIP. The community needs a specification to coalesce around, even if it evolves. Without a concrete target, every team will defer PQ work indefinitely.

One more observation: the EF’s leadership instability (three executive directors in two years) is particularly concerning in the context of a multi-year infrastructure migration. PQ migration needs consistent leadership and sustained attention span. I hope the new co-ED structure provides that stability.

zk_proof_zoe · February 18, 2026, 7:21pm

Brian, I want to address your point about leanVM specifically, because I think the architectural choice they are making has implications that go beyond just PQ migration.

leanVM as a Precedent for Execution Layer Modularity

If leanVM ships as a specialized ZK verification layer for PQ signatures, it establishes a precedent: Ethereum can have multiple execution environments running in parallel, each optimized for specific cryptographic operations. This aligns interestingly with the RISC-V discussion that has been happening since Vitalik’s proposal.

Think of it this way:

EVM: General-purpose smart contract execution
leanVM: Optimized PQ signature verification via ZK proofs
Future RISC-V environment: Potentially replacing EVM for general execution

The PQ migration might accidentally accelerate Ethereum’s execution layer modularity, which would be a significant architectural evolution.

However, I have a concern about the ZK proof layer approach. Generating a ZK proof that attests to a PQ signature’s validity is not free. Someone needs to compute that proof, and the proving cost for PQ signature verification in a ZK circuit is non-trivial.

For ML-DSA (Dilithium) verification, the arithmetic circuit involves:

NTT (Number Theoretic Transform) operations over polynomial rings
Modular arithmetic in Z_q where q = 8380417
Hash function evaluations (SHAKE-256)

None of these are particularly efficient in current ZK proving frameworks. The proving time for a single Dilithium signature verification could be 1-5 seconds on consumer hardware, which means users would need to wait or outsource proving to a specialized service.

This creates a centralization pressure: proving-as-a-service providers would handle PQ signature proving, adding another intermediary between users and the protocol. For a network that values decentralization, this is a meaningful trade-off.

I think the EF’s approach is sound in principle, but the second-order effects on decentralization and user experience need more discussion. A proving delay of 1-5 seconds per transaction is acceptable for high-value transfers but could be problematic for real-time DeFi interactions.

Your call for cross-client testing and public testnets is exactly right. The faster we can get real performance data, the faster we can identify and address these practical bottlenecks.

startup_steve · February 18, 2026, 7:21pm

Brian, I appreciate the technical depth here, but I want to bring the business reality perspective because I think there is a disconnect between how researchers frame this problem and how startup founders and product teams experience it.

The “PQ Migration Plan” Problem for Startups

You said every team should have a post-quantum migration plan. I run a pre-seed Web3 startup with a 5-person team. Here is my honest reaction to that recommendation:

We are currently focused on:

Shipping a working product
Getting to 1,000 users
Raising our seed round
Not running out of money

Adding “design for post-quantum migration” to that list is like telling someone who is trying to not drown to also consider their retirement portfolio. It is technically correct and practically impossible given our constraints.

And I suspect we are representative of 90% of Web3 startups. The teams that will actually implement PQ migration plans are large, well-funded protocols with dedicated security teams. The long tail of smaller projects will either migrate reactively (when there is a concrete hard fork deadline) or die.

The Business Case for PQ Investment

That said, your cost comparison table (EF’s $2M vs. China’s $15B) is genuinely alarming. And it made me think about this differently.

For investors, the quantum threat creates an interesting dynamic. If you are evaluating two competing protocols and one has started PQ migration work while the other has not, the PQ-prepared protocol has a meaningful competitive advantage. Not because quantum computers will arrive tomorrow, but because:

It demonstrates long-term thinking and technical depth
It reduces future migration risk and cost
It signals to institutional investors that the team takes existential risks seriously

I have seen this play out in other industries. Companies that started Y2K preparations early had a competitive advantage over those that scrambled at the last minute, even though the actual risk turned out to be minimal.

So maybe the right framing for startups is not “build for PQ now” but rather “make architectural choices today that do not lock you out of PQ migration later.” Use account abstraction patterns, keep your cryptographic dependencies modular, and choose STARK-friendly proof systems when there is a choice.

That is a much more actionable recommendation than “have a PQ migration plan,” and it does not require dedicated PQ engineering resources that most teams simply cannot afford.

One question for the group: are there any PQ-aware smart contract templates or starter kits being developed? A Foundry template that uses abstract signature verification would go a long way toward making PQ-readiness the default rather than an afterthought.