Post-Quantum Roadmap
TL;DR
EIP-8141 does not solve post-quantum security for Ethereum. It is the first step in a long roadmap requiring multiple coordinated protocol upgrades before Ethereum accounts are truly quantum-safe. The roadmap spans seven stages: decoupling accounts from ECDSA, PQ precompiles, ephemeral key rotation, encrypted mempools, complete secp256k1 revocability, native PQ transactions, and private L1 settlement.
The Ethereum L1 Strawmap identifies post-quantum L1 as one of five "north stars," targeting "centuries-long cryptographic security via hash-based schemes" through seven forks by end of 2029. The urgency is real: Google's Q-Day research estimates elliptic curve cryptography could be broken with fewer than 500,000 physical qubits in minutes, with 2029 as the projected timeline. Each stage builds on the previous one; skipping stages creates gaps a quantum adversary could exploit.
EIP-8141 is the foundational primitive that makes the rest possible. Without account decoupling from ECDSA, none of the subsequent stages have a protocol surface to build on.
1. Foundation: Decoupling Accounts from ECDSA
Status: EIP-8141 (Draft), Scheduled for Inclusion in the Hegotá fork via PR #12251 (merged Aug 27, 2026, after ACDE #244) and confirmed as its headliner at ACDE #245. Vitalik's case at ACDE #244 was explicitly PQ: frames support hash-based signatures without new precompiles and leave room for STARK mempool aggregation.
Today every Ethereum account is bound to a secp256k1 key pair. Shor's algorithm can recover the private key from an exposed public key in polynomial time. EIP-8141 breaks this coupling: VERIFY frames let any account code define its own signature verification, and the outer signatures list can carry protocol-validated P256 signatures or ARBITRARY custom witness bytes. EOA default code gives existing codeless EOAs secp256k1 frame authentication without deploying a smart contract, but it does not make those EOAs passkey/P256-authenticated by default.
The frame architecture is deliberately generic, providing foundational primitives (VERIFY frames, APPROVE, per-frame gas) without prescribing which PQ scheme to use. This gives the ecosystem time to research PQ curves before committing.
Delivers: the protocol surface for PQ migration. Does not deliver: actual quantum safety. Default code still signs with secp256k1, and P256 is also quantum-vulnerable even where account code uses it. The ECDSA key remains the master key unless account code or a future EIP revokes it.
⎯ Where EIP-8141 ends, the roadmap begins ⎯
Stage 1 above is what EIP-8141 itself delivers and is what the rest of this site documents. Stages 2 through 7 below are future research: separate EIPs, separate forks, separate open questions. EIP-8141 is a prerequisite for each of them but does not implement any of them. If you are reading this page for what ships in Hegotá, stop at Stage 1; the rest is the direction of travel.
2. PQ-Ready Precompiles and Opcodes
Status: EIP-8288 merged (not scheduled); EIP-8397 merged; precompiles in research (EIP-8051, EIP-8052); EIP-8355 ML-DSA precompiles declined for Hegotá
PQ signature schemes are expensive. Falcon-512 costs over 1M gas in the EVM; Dilithium and SPHINCS+ are similarly costly. Dedicated precompiles are needed, following the path P256 took via RIP-7212 (~3,450 gas).
EIP-8141 decouples PQ scheme selection from the transaction format: as precompiles ship, accounts adopt them by updating VERIFY frame logic, no protocol changes needed. The signatures list (PR #11481, merged May 22; repaired by #11837/#11814 in July) adds forward-compatibility with signature aggregation, critical since PQ signatures are large (Falcon: ~666 bytes, Dilithium: ~2,420 bytes). Protocol-validated raw bytes remain hidden from EVM code for aggregation, while ARBITRARY entries cost 100 gas and carry custom witnesses. PR #12187 split access into static-shape operations: SIGPARAM returns witness length and SIGDATACOPY copies bytes. Raw signature bytes with empty msg are elided from the canonical hash. The proposed explicit registry in PR #12011 closed Jul 29; future fixed-cost schemes remain separate specification work.
EIP-8288 (PR #11772, vbuterin and Thomas Coratger) merged Sep 9 and was renamed "In-mempool signature and proof aggregation". It adds a non-executed DEP_VERIFY_FRAME_MODE (now mode 4) declaring (scheme, data_hash, verification_key_hash) dependencies and a block-header recursive_stark that aggregates every dependency in the block into one recursive STARK. LEANSPHINCS_SCHEME = 0x10 costs 3,000 gas; LEANSTARK_SCHEME = 0x11 is reserved until its digest is defined (#12417), so only hash-based leanSPHINCS dependencies are usable today. b-wagn's recursive-soundness concern was deferred to the STARK data type and listed as a trust assumption; a mode-1 wrapper binding gap found by chugarchugarr was closed by #12436. Proof placement (block body vs payload field) and FOCIL proofs remain open, and the EIP is not tracked in the Hegotá meta-EIP.
ACDE #247 (Oct 8) declined EIP-8355's ML-DSA precompiles over lattice concerns, with Vitalik suggesting the effort go to EIP-8288 instead. EIP-8397 (merged Oct 14) adds an AUTHENTICATOR signature scheme whose fixed 50,000-gas, state-independent check keeps proofs hidden for aggregation. The PQTS breakout's Daisugi testnet added native frame transactions in v0.2 and targets EIP-8288 aggregation next, and AnkushinDaniil's ERC-8403 post sketches leanSPHINCS keys as account-authority leaves whose signatures go to the block proof.
Delivers: practical gas costs for PQ verification, and (via EIP-8288 once scheduled) the recursive-STARK block-level aggregator that makes per-tx PQ signatures economically viable at scale. Does not deliver: mempool-level key protection or legacy key revocation.
Address derivation gap: EIP-8215 Hash-Committed Account is a complementary open proposal for new accounts whose addresses derive from a Merkle root of spending conditions rather than a public key. Its own framing is that EIP-8141 upgrades validation for existing accounts, while HCA lets new accounts be born without a public-key-derived address. It does not replace EIP-8141's transaction model; it fills a different PQ gap.
3. Ephemeral Key Pairs
Status: Research (ethresear.ch, March 2026)
Even with PQ precompiles, the public key is exposed in the mempool between broadcast and inclusion. A quantum adversary could recover the private key and frontrun.
Ephemeral key pairs (proposed by mvicari) make every signing key single-use: each transaction rotates the authorized signer to a fresh address, permanently retiring the previous key. An EOA that has never transacted is quantum-safe because its public key is hidden behind a hash. Ephemeral keys ensure each key is used exactly once.
Under EIP-8141, this is expressible natively: VERIFY frames check the current signer, SENDER frames rotate to the next one, key derivation follows BIP-44 paths. Gas overhead is ~136k per ERC-20 transfer in the PoC (~100k above baseline), reducible by stage 2 precompiles.
Delivers: quantum safety against mempool-level key extraction. Does not deliver: protection against builders/proposers who see plaintext transactions.
4. Encrypted Mempools
Status: EIP-8184 (Draft, March 2026)
Ephemeral keys shrink the exposure window but do not eliminate it. EIP-8184 (LUCID) closes this gap with sealed transactions that propagate encrypted, revealed only after ordering is finalized:
- User broadcasts a sealed transaction: signed ticket (for charging) + ciphertext envelope
- Includers propagate via FOCIL inclusion lists
- Builders commit to bundles via hashes before seeing plaintext
- Key publishers release decryption keys after block commitment
- Decrypted transactions execute against the prior block state
EIP-8184 is PQ-forward-compatible: its signature_id field is extensible beyond the current EC_DSA_TYPE, and it describes an explicit EIP-8141 integration path where sealed transactions appear inside frame transactions. It requires EIP-7805 (FOCIL). See also Mempool Strategy → Encrypted Mempool Compatibility.
Delivers: complete concealment of signatures and public keys until after ordering. Does not deliver: revocation of the legacy secp256k1 key.
5. Complete secp256k1 Revocability
Status: EIP-8298 and EIP-8151 CFI for Hegotá (ACDE #247, Oct 8) as the PQ EOA-migration path; EIP-7851 declined for Hegotá (ACDE #245); EIP-8164 Draft.
As long as the original secp256k1 key retains authority, the account has a quantum-vulnerable surface. Complete revocability means permanently removing the ECDSA key as an authorized signer: legacy transaction types must be rejected for the account, deployed ecRecover-based contracts (such as ERC-2612 permit) must stop honoring the key, and recovery for lost PQ keys must exist.
The Hegotá path pairs two EIPs with frames:
- EIP-8298 (
SETCODEFROM, opcode0xA7) lets an EOA adopt an existing contract's code in place. Under EIP-3607 an account with regular code cannot send legacy transactions, so the key loses transaction authority while the account "keeps transacting as the sender of EIP-8141 frame transactions that its code approves." - EIP-8151 (Account Code Restricted
ecRecover) returns empty output when the recovered address has code other than a 7702 delegation indicator, sopermit-style contracts stop honoring retired keys without redeployment.
Two open EIP-8141 PRs complete the pairing: #12506 would let default code run SETCODEFROM from a SENDER frame so a codeless EOA can migrate in one frame transaction, and #12505 would stop protocol-validated signatures from authorizing for signers that adopted code. nezu511 showed (post #179) that EIP-8151 makes ecrecover a code-dependent read the 8141 mempool does not yet track.
EIP-7851, now "Code-Controlled EOA Delegation", covered 7702-delegated EOAs and was declined for Hegotá. EIP-8164 (Native Key Delegation) remains a parallel track: its 0xef0101 Ed25519 accounts run no code, so they cannot originate frame transactions.
Delivers: a scheduled-fork path to retire ECDSA authority for any EOA by adopting code that frames can drive. Does not deliver: recovery for lost PQ keys, protocol-wide ECDSA removal, or a composable EIP-8164 path.
6. Native Post-Quantum Transactions
Status: Strawmap target (end of 2029)
With all building blocks in place, Ethereum ships native PQ transactions as a protocol feature. The strawmap envisions leanXMSS for signatures and STARK-based compression via leanVM:
- Fork I (~H1 2027): Validator PQ key registration
- Fork J (~H2 2027): Gas efficiency for PQ signatures
- Fork L (~H2 2028): State compression via ZK proofs
- Later forks: Full PQ consensus
In practice: frame transactions with PQ precompile VERIFY frames, restrictive-tier mempool validation, ephemeral key rotation, encrypted propagation, and revoked ECDSA keys. EIP-8141 provides the transaction format this composes into, without requiring a new tx type for each capability.
7. Long-Term: Private L1 Settlement
Status: Research direction
The PQ roadmap converges with native privacy via shielded transfers, another strawmap north star. A fully private L1 combines PQ authentication, encrypted propagation, shielded transfers (concealed amounts/parties), and ZK state proofs.
Proposals pointing in this direction: EIP-8224 (fflonk ZK proofs for shielded gas funding), the expansive mempool tier for privacy protocols, and the merkle branch escape hatch for witness data. EIP-8141's frame architecture provides the protocol surface that PQ verification, encrypted propagation, and shielded transfers all build on.
The three-gates analysis identifies what must change for shielded-pool withdrawals to reach a block through public infrastructure rather than a private relayer: canonical-pool code-hash exemption, raised VERIFY caps (~400k per tx, 1M per inclusion list), and validation-index FOCIL enforcement.
Roadmap Summary
| Stage | Component | Status | Depends on |
|---|---|---|---|
| 1 | Account decoupling from ECDSA | EIP-8141 (Draft, SFI for Hegotá) | - |
| 2 | PQ precompiles, aggregation, and authenticators | EIP-8288 and EIP-8397 merged; EIP-8051, EIP-8052 research | Stage 1 |
| 3 | Ephemeral key rotation | Research (ethresear.ch) | Stages 1, 2 |
| 4 | Encrypted mempools | EIP-8184 (Draft) | Stage 1 |
| 5 | Complete secp256k1 revocability | EIP-8298 + EIP-8151 (CFI for Hegotá); EIP-8164 Draft and parallel to EIP-8141 | Stages 1-4 |
| 6 | Native PQ transactions | Strawmap target (end of 2029) | Stages 1-5 |
| 7 | Private L1 settlement | Research direction | Stages 1-6 |
EIP-8141 is necessary but not sufficient. It builds the foundational first step by decoupling account authentication from ECDSA and providing the generic transaction primitives that all subsequent PQ work builds on. A long sequence of protocol upgrades, precompiles, and eventually full ECDSA deprecation must follow before Ethereum is truly post-quantum safe. This roadmap is measured in years, not months.
Read Next
- Current Spec → EOA Default Code — where Stage 1 actually lives, in spec terms.
- Mempool Strategy — how encrypted mempools (Stage 4) interact with the two-tier design.
- Competing Standards — which alternatives are also PQ-ready, and which are not.
Sources: EIP-8141 Spec, EIP-8184 (LUCID), Ephemeral Key Pairs (ethresear.ch), Ethereum L1 Strawmap, Post-Quantum Ethereum, Google Q-Day Timeline, EIP-8051, EIP-8052, EIP-7851, EIP-8151, EIP-8164