Bitcoin and Ethereum Go Different Quantum-Safe Wallet Paths
Currently, neither Bitcoin nor Ethereum offers native, quantum-resistant wallet options for their users. As of October 22, 2026, both networks have ongoing proposals and research code, but no released wallet changes the rules governing existing funds. Indeed, this distance between proposed drafts and actual signing capabilities defines each chain’s current position.
The two networks are adopting different approaches due to their distinct account models. Bitcoin would require a soft fork to modify spending conditions. Ethereum’s programmable accounts, however, can execute custom verification code without a network-wide protocol change, although this doesn’t revoke the original classical key.
Both methods leave existing holdings vulnerable to the same theoretical risk: a future quantum computer capable of recovering a private key from a public key that has been visible on-chain.
BIP-360: Scope and Limitations
Bitcoin Improvement Proposal 360, known as Pay-to-Merkle-Root (P2MR), suggests removing Taproot’s key-path spending option. Instead, spending would occur through a tree of scripts. The aim is to reduce exposure from public keys that remain visible on-chain for extended periods, a condition that a quantum attack would exploit.
Crucially, P2MR doesn’t introduce a post-quantum signature scheme. This is a point many readers overlook. Though the proposal reduces the frequency of a raw public key exposure, it doesn’t address a separate issue: the brief window during which a spending transaction reveals a public key before confirmation.
Several details highlight the early stage of this development:
- BIP-360 is still a draft, with test vectors and a Python implementation, yet one test still requires a secp256k1 signature.
- SHRINCS, a draft hash-based signature scheme intended to authorize Bitcoin transactions, is separate from P2MR and lacks a published specification or reference code that would alter rules for existing holdings.
- Bitcoin Core’s 31.0 wallet supports legacy, wrapped SegWit, native SegWit, and Taproot address types. The 31.1 release includes fixes but does not introduce P2MR or any post-quantum signing path.
For production implementation, agreement on validation rules and wallet software capable of creating, signing, and recovering funds under the new conditions would be necessary. None of this has been deployed.
Ethereum’s Smart Accounts Offer a Different Approach
Ethereum doesn’t require a protocol feature to verify an alternative signature. Smart accounts can execute custom authorization logic as standard EVM code. The SPHINCS-based research project provides verifiers that perform precisely this function, and its documentation distinguishes Sepolia test transactions from EIP-8141 frame transactions executed on the ethrex privacy testnet.
These experiments don’t equate to a mainnet activation. EIP-8141 is still labeled as a Draft. It introduces “frame transactions” that allow code to define validation and fee payment, which its authors describe as a native method for moving away from elliptic-curve authentication. However, the released Geth v1.17.9 transaction decoder doesn’t accept the proposed type, which means the code isn’t live on the critical main network.
The research implementation includes a clear warning: its unaudited code is “not safe to use with real funds.” The Ethereum Foundation’s post-quantum team has identified account abstraction and specialized verification as components of its execution-layer plan, but this roadmap remains subject to ongoing research and open governance.
A limitation that runs deeper than any single proposal is that an existing externally owned account retains the authority of its original classical key; adding contract logic doesn’t erase it.
Under EIP-7702, a valid authorization from that key can replace or clear an account’s delegation, and a delegated account can still send ordinary transactions. Testing validator signatures is distinct from altering the mechanism that controls a holder’s funds.
Hardware Signing vs. Network Acceptance
Chip-level support represents a separate layer of this transition and can be easily misinterpreted. Ledger said it has implemented ML-DSA signing in its software development kit. This provides developers with the cryptographic function but doesn’t change which signatures Bitcoin or an Ethereum account will accept.
This pattern holds universally. New algorithms, successful testnet transactions, and hardware signing all exist without modifying the rules or wallet features that govern existing balances. For a holder, the pertinent question remains narrow: can my wallet create, sign, and recover funds using a quantum-resistant scheme on mainnet today? For both chains, the answer is currently no.
Europol has identified crypto wallets as a primary target for future quantum attacks, which is the threat model driving this work. European regulators are also establishing formal expectations for post-quantum migration, evident in guidance such as Germany’s BSI TR-02102, though these frameworks primarily target institutional cryptography rather than wallet signing.
The Challenge for Privacy Chains
Meanwhile, the signature question is not the only quantum exposure in cryptocurrency. Zcash developer Zakura has proposed a wallet-level change to address a narrower risk: linkability in shielded cross-chain swaps. When a shielded address is published during a swap routed through NEAR Intents, a future quantum computer capable of deriving a viewing key from that exposed address could link the payments associated with it.
Zakura’s design would derive a separate incoming viewing key for each swap and keep funds spendable from the user’s original account. The goal is to limit any future visibility to a single swap as opposed to a user’s entire payment history.
That said, the risk is theoretical, depending on non-existent quantum capabilities and an exposed address. The design is attributed to Zakura as a proposal, with no independent cryptographic review or formal acceptance by Zcash maintainers confirmed. It addresses privacy compartmentalization, not post-quantum transaction signatures, which Zcash tracks as a separate aspect of quantum-readiness work.
The Defining Metric for These Projects
Across Bitcoin, Ethereum, and Zcash, the crucial distinction remains consistent. A proposal, a testnet demonstration, and hardware capability all advance the work without changing what a mainnet wallet will accept.
Precise language is key: BIP-360 is drafted, not activated; EIP-8141 is drafted, not accepted; ML-DSA signing is integrated into an SDK, not recognized by either network; Zakura’s keys are proposed, not shipped.
For holders, the practical step today is to monitor which wallet releases incorporate signing and recovery for a quantum-resistant scheme on mainnet. None of the developments mentioned above have reached that stage yet.
For more information on how PQC, QKD, and QRNG perform different functions, and where standardized schemes like NIST FIPS 203 fit alongside proprietary ones, follow QNews’ coverage of post-quantum cryptography and wallet security.