By cryptoadmin As of Oct. 22, 2026, existing Bitcoin and Ethereum holders do not have a native, drop-in replacement for their ordinary transaction signatures. Bitcoin’s proposed quantum-resistant output structure remains a draft; Ethereum can run post-quantum verification in smart contracts, but its proposed native route away from elliptic-curve authentication is also still a draft.
The practical distinction is where protection can be enforced. Bitcoin’s BIP-360, called Pay-to-Merkle-Root or P2MR, proposes new spending conditions through a soft fork. Ethereum’s programmable accounts can already use custom verification logic without a hard fork, although that does not automatically remove the original signing key’s authority over an existing account.
For holders, an algorithm implementation, a test transaction and a released wallet feature are therefore different milestones. The SPHINCS- Ethereum research implementation documents test deployments, but explicitly warns that its unaudited code is “not safe to use with real funds.” Bitcoin Core’s released wallet still offers conventional address types rather than a post-quantum option.
Bitcoin: A New Output Is Not a New Signature
BIP-360 would remove Taproot’s key-path spending option, committing instead to a tree of spending scripts. Its purpose is to protect against attacks on public keys exposed for long periods. The specification explicitly says it does **not** introduce post-quantum signature schemes; protection during the interval when a spending transaction exposes a key before confirmation requires further work.
That separates P2MR from SHRINCS, a draft hash-based signature scheme intended for Bitcoin transaction authorization. Neither publishing a specification nor supplying reference code changes the spending rules protecting existing coins. BIP-360 includes test vectors and a Python implementation, including a test that still requires a secp256k1 signature.
Released wallet support is a separate dependency. The Bitcoin Core 31.0 wallet documentation lists legacy, wrapped SegWit, native SegWit and Taproot address options. The subsequent 31.1 release adds fixes, not P2MR or post-quantum signing. A production transition would require agreed validation rules as well as wallets able to create, sign and recover the new holdings.
Ethereum: Contract Verification Is Already Possible
Ethereum has a different starting point: smart accounts can define their own authorization logic. The SPHINCS- project supplies verifiers that run in ordinary Ethereum Virtual Machine code, without a new protocol feature. Its current deployment documentation distinguishes Sepolia test transactions from EIP-8141 frame transactions on the ethrex privacy testnet. Those are not Ethereum mainnet activation of EIP-8141 or a production wallet release.
EIP-8141, still labeled Draft, proposes frame transactions that let code define validation and fee payment. Its authors describe it as a native route away from elliptic-curve authentication. The released Geth v1.17.9 transaction decoder does not accept that proposed transaction type.
The Ethereum Foundation’s post-quantum team describes account abstraction and specialized verification features as its execution-layer strategy. Its roadmap is subject to research and open governance, not a guarantee that wallets already support migration. Validator-signature testing is also a separate task from changing authorization over a holder’s funds.
Hardware capability is another distinct layer. Ledger says it has implemented ML-DSA signing in its SDK. That supplies developers with cryptographic machinery; it does not change which signatures Bitcoin or an Ethereum account accepts.
For background, The Defiant’s Willow report separates quantum experiments from modeled key attacks. Its curve-origin report concerns public parameters, while the ECDSA explainer explains signing and verification.
For an existing Ethereum externally owned account, adding contract logic alone does not retire its classical authority. Under EIP-7702, a valid authorization from the original key can replace or clear the delegation, and a delegated account can still originate ordinary transactions.