You can find the latest draft of our proposal on our GitHub repository.
Introduction
Ethereum’s long-term security depends on the hardness of elliptic-curve cryptography. A credible quantum breakthrough would render existing accounts vulnerable, exposing all assets secured by elliptic curve cryptography (ECC). Current mitigation plans focus on replacing the signature scheme at the protocol level, e.g. through new transaction types, precompiles, or consensus-layer upgrades. Such changes will require a hard fork and years of coordination, all the while users’ funds remain dependent on ECC. In the event of a quantum emergency, protocol-level post-quantum EIPs juts couldn’t deploy fast enough to save the ecosystem.
We propose a different approach, built on existing capabilities of the Ethereum stack. While protocol-level proposals aim to replace ECC at the consensus layer — by upgrading key material — we instead leverage Account Abstraction (cf. ERC4337 and EIP7702) to establish a user-space migration path:
- Users prove account ownership using quantum-resistant zero-knowledge proofs, implementable today in both hardware and software wallets.
- Proof verification occurs entirely on-chain at Layer 1, with no hard forks, no new transaction types, and no trusted intermediaries.
- No modification is required to existing or future dapps, thanks to account delegation mechanics already available in Ethereum today.
By operating at the account layer, our approach preserves full protocol compatibility, while providing an immediately deployable migration mechanism. Ethereum can achieve practical protection before the protocol itself completes a quantum transition, something no other proposal currently enables. This realizes the graceful emergency fallback envisioned in Buterin’s 2024 proposal, but makes it operational today.
Account Abstraction
In Ethereum, externally owned accounts (EOAs) are hard-coded to authenticate through signatures based on elliptic curve cryptography (ECC). Account Abstraction (AA) — defined by ERC4337 and related proposals — moves authentication logic into contract space instead, allowing any smart contract to act as a fully functional account. This introduces a programmable authentication substrate to Ethereum, which we can leverage to build a quantum-safe migration path without requiring an early hard fork.
In our design, users migrate from traditional EOAs to quantum-safe ERC-4337 smart accounts. Instead of relying on ECC-based signatures, the smart accounts prove ownership by demonstrating knowledge of the seed phrase from which the EOA address was derived, e.g. via BIP-32 hierarchical deterministic derivation (cf. also BIP-39 and BIP-44). The proof takes the form of a STARK (see e.g. Ben-Sasson 2018), a succinct, transparent and quantum-resistant flavour of zero-knowledge proofs. STARK proofs are generated off-chain and verified by on-chain logic. This derivation approach is inspired by Buterin’s 2024 proposal and closely related to a 2023 proposal by Or Sattath and Wyborski.
The original EOA is not modified, but rather serves as the source of verifiable ownership which seeds the authority for the quantum-safe smart account. Using mechanics such as ERC-20 and ERC-721 approvals, permit-based authorisations (cf. ERC2612 and ERC4494), or ERC-4337 delegated operations, users can delegate the quantum-safe account to perform token transfers and dapp operations on behalf of the legacy EOA, establishing continuity of control. Once EIP-7702 is approved, EOAs can run STARK-based authorisation logic on their own, as a mechanism alternative to ECC-based signatures.
The key insight of our proposal is that Account Abstraction makes it possible for Ethereum to handle a quantum emergency entirely at the consensus level, with no immediate changes needed to the core protocol. We now describe some of the specifics.
Quantum-safe accounts can be deployed by sponsoring parties on behalf of any EOAs which have not yet migrated, because authentication is tied to proof of knowledge of the original seed phrase. This allows a considerable portion of EOAs to be protected in an emergency, not just the ones with the foresight or technical know-how to perform an early migration. It is impossible to conclusively determine the approximate number of EOAs whose addresses arise by hierarchical deterministic derivation, but estimates based on popular wallets — both hardware and software — place a realistic lower bound estimate around the majority line.
While we will endeavour to support as many EOAs as possible, there is an ultimate limitation to our approach. Unless the private key was derived by means of some quantum-resistant one-way function, there is no purely cryptographic way to definitively determine the ownership of an EOA once advanced quantum capabilities have been demonstrated. In the absence of pre-emptive migration steps, such situations will likely require off-chain resolution.
A gas vault, coupled with gas sponsorship mechanics, can be used to reduce the financial burden caused by the additional complexity of on-chain STARK verification. A fraction of the vault can be dedicated to sponsoring early user adoption, with the majority unlocked by custodians in case of an emergency.
Broad integration of the proposal into wallet hardware and software will be necessary for seamless UX. At the enclave/internals level, this consists primarily of the generation of STARK proofs from seed phrase material. At the interface level, this includes deployment and operation of the quantum-safe accounts, one-click delegation for tokens and dapps, and access to gas sponsorship. Note also that the quantum-safe account address can be deterministically derived from the corresponding EOA address, making it possible to safely associate the two well in advance of an emergency.
The handling of an emergency at consensus level requires validators to stop accepting any transactions from EOAs, other than a standardised set of delegations to the associate quantum-safe accounts, including the transfer of Ether. The deployment and operation of quantum safe accounts proceeds normally, without protocol changes.
From a technical perspective, finally, this proposal greatly benefits from the introduction of a kill-switch into validator software. The economics of staking make it in the best interest of validators, as a collective, to protect the chain from malicious transactions in the event of a quantum emergency. While the decision to operate the kill-switch is ultimately left into the hands of validators, in accordance with their mandate as ultimate custodians of chain integrity, on-chain oracles integrated at the software level will likely be used to coordinate the response in an emergency.
Proof of Seed
A key step in our mitigation proposal is the implementation of signature lifting, the transformation of a quantum-weak authentication scheme — such as ECDSA, EdDSA, or Schnorr signatures — to a quantum-resistant one via zero-knowledge proof of the pre-image for some cryptographic hashing step which was performed as part of the key derivation algorithm.
Signature lifting is a broad technique, applicable to a wide variety of key generation pipelines, but for sake of concreteness we focus specifically on BIP-32 hierarchical deterministic wallets, arguably the most common key derivation technique in use today.
The BIP-32 key derivation spec presents multiple opportunities for signature lifting. Every private child key is derived from a parent private key via an application of HMAC-SHA512: if a parent/ancestor public key has not been exposed, knowledge of the parent/ancestor private key can be used as a witness for signature lifting of the child key. If the public master key has not been exposed, the master private key be used as a witness for all other keys, hardened or not.
There is, however, the possibility that the public master key has itself been exposed, and hence that the private master key is vulnerable to quantum attacks. The private master key is itself derived from a master seed via an application of HMAC-SHA512. The master seed is not exposed — unless compromised, see below — and knowledge of its value can be used as a witness for signature lifting of the master keypair itself.
Lifting opportunities for BIP-32 end at the master seed: in case of compromise, there might not be a further step available for lifting. If the master seed has been derived from a BIP-39 mnemonic, however, signature lifting becomes possible even in case of master seed compromise. Indeed, the BIP-39 spec prescribes 2048 applications of HMAC-SHA512 to derive the master seed from the UTF-8 NFKD bytes of a mnemonic sentence: as wallets typically store the master seed itself, rather than any of the intermediate hashes, the preimage to the last (or last few) HMAC-SHA512 applications is unlikely to have been compromised, and it can be used as witness for post-quantum lifting of the master seed itself. Unfortunately, nothing further can be done in case of mnemonic compromise.
Having laid out the plan, the challenge shifts to implementation. We have two desiderata:
- The zero-knowledge proof generation process must be suitable for execution on a variety of platforms and architectures, since it must be possible to integrate it with almost all wallets in current usage.
- The zero-knowledge proof verification process must suitable for execution on-chain, as part of the Account Abstraction framework, and in particular both proofs and verifier must be succinct.
Here, we encounter a problem: zero-knowledge technology has progressed enormously over the last few years, but a fundamental compromise remains to be made between succinctness at the verifier side and workload at the prover side. The vast majority of recent efforts have been focused in the direction of making proofs lightweight and succinct, but often at the expense of heavier prover workloads.
STARK verifiers are already used in production for on-chain verification, and recent proposals (cf. EIP-7885 and the NTT precompile) are poised to make the process more efficient. This makes STARKs very attractive for the verification side of proof of seed. Unfortunately, the STARK proof generation process is extremely computational intensive: while they might be streamlined enough to be workable on portable devices, there is no realistic prospect of compatibility with secure elements, the higher end of the wallet security ladder.
Secure elements are widely used as hardware wallets, performing critical computations in a tamper-resistant environment. However, these devices often impose a number of stringent limitations on computational resources, the terminal blocker for STARK prover implementation being available RAM in the order of a few dozen KBs.
While memory constraints rule out the vast majority of modern general-purpose, public-verifier ZK protocols, an important exception is represented by MPC-in-the-Head (MPCitH) protocols such as ZKBoo, where succinctness on the verifier side is traded for a significantly lighter workload on the prover side.
With a number of considerations, which will be discussed in a separate post, the ZKBoo protocol can be tweaked to generate proofs in a fully streamed fashion, with memory requirements independent of the trace length of the prover, the length of the individual proof responses, or the security parameter of the proof. This brings memory requirements for proof generation down to within a small factor — slightly above 3x — of the minimal memory requirements for the computation being proven, well within the capabilities of secure elements such as those used by Ledger wallets.
A critical limitation of ZKBoo — and one of the reasons why it doesn’t hold much mindshare in the modern zero-knowledge landscape — is that neither its proofs nor its verifier are succinct, in that both the size of the former and the runtime of the latter are linear in the trace length. This makes ZKBoo proofs unsuitable for direct use in the on-chain verification process, but that was not the reason why this technique was chosen: its job is to allow the practical extraction of a proof of knowledge from a computationally constrained secure environment, wrapped into a zero-knowledge container.
Once the ZKBoo proof has been produced, more powerful machines can be used to perform a second step of recursive verification, resulting in succinct lifting: where the ZKBoo proof might prove the statement “I know the seed from which this public key was derived”, the lifted proof would succinctly prove the statement “I known a valid ZKboo proof for the statement that I know the seed from which this public key was derived.”.
Importantly, the external machine performing the succinct lifting does not need to be trusted, because the ZKBoo proof itself already guarantees zero-knowledge. For the same reason, the technique used for succinct lifting does not itself need to be zero-knowledge. This latter observation opens the door to applications of succinct ZK systems — such as ones for binary fields — which may be well-suited to proving statements heavy in bitwise operations — such as those involved in the ZKBoo proof verification — but might not themselves be formulated in a zero-knowledge way.