Key Highlights:
- Bitcoin proposal BIP-360 alters Taproot spend paths to conceal public keys, but explicitly does not introduce post-quantum signatures or protect exposed keys during transaction broadcast.
- Ethereum smart accounts can already verify hash-based signatures like SPHINCS+ via the EVM, though native solutions like EIP-8141 frame transactions remain in early draft and testnet stages.
- Hardware wallet tools such as Ledger’s ML-DSA SDK integration provide cryptographic groundwork without altering the consensus validation rules currently enforced by major networks.
Architectural Approaches to Post-Quantum Cryptography in Blockchain
As research into quantum computing accelerates, developers across major distributed ledger networks are evaluating methods to secure existing and future digital assets. The two largest networks, Bitcoin and Ethereum, are pursuing fundamentally different architectural paths toward quantum resistance. While Bitcoin relies on disciplined script-level and base-layer changes that require extensive network consensus, Ethereum leverages its execution environment and smart contract programmability to prototype signature verification without immediate consensus upgrades.
Despite these technological strides, neither network has implemented end-to-end, production-ready quantum immunity for everyday user transactions. Current proposals and test implementations highlight the sharp boundary between theoretical cryptographic primitives and live consensus enforcement across mining nodes, validators, and user wallets.
Bitcoin: Script Changes vs. Cryptographic Signatures
Within the Bitcoin ecosystem, proposal BIP-360 proposes Pay-to-Merkle-Root (P2MR), an approach that alters Taproot’s spending structures by eliminating the key-path spend option and committing solely to a tree of spending scripts. The primary design goal of BIP-360 is to safeguard funds against quantum attacks directed at public keys that remain exposed on-chain over long durations. However, the proposal explicitly notes that it does not implement post-quantum signature algorithms. Consequently, transactions remain vulnerable during the mempool interval when a spending transaction broadcasts its public key before block confirmation.
This structural boundary sets BIP-360 apart from distinct efforts like SHRINCS, a draft hash-based signature scheme designed for Bitcoin transaction authorization. Although BIP-360 provides a Python reference implementation and test vectors, its tests still rely on secp256k1 elliptic-curve signatures. Software deployment remains far from consumer availability; the Bitcoin Core 31.0 documentation retains legacy, nested SegWit, native SegWit, and Taproot options, while the subsequent 31.1 maintenance release delivers minor bug fixes rather than P2MR or post-quantum signature schemes. Full production rollout would require broad consensus activation along with wallet ecosystems capable of generating, signing, and recovering the revised script types.
Ethereum: Smart Account Verification and EIP-8141
Ethereum’s account abstraction model provides an alternative route, permitting smart contract accounts to execute custom authentication code directly on the Ethereum Virtual Machine (EVM). Through the SPHINCS+ project, developers can already deploy signature verifiers written as standard EVM smart contracts without modifying underlying protocol rules. Current project documentation outlines experimental transactions deployed on the Sepolia testnet alongside experimental EIP-8141 frame transactions running on the ethrex privacy testnet, neither of which represents an Ethereum mainnet activation.
EIP-8141, which remains designated as a Draft, introduces frame transactions designed to allow arbitrary code to govern transaction validation and gas fee payments. The proposal’s authors present it as an integrated, native pathway away from classical elliptic-curve signatures. Nevertheless, core production clients remain unconfigured for such features; the released Geth v1.17.9 transaction decoder does not recognize the proposed frame transaction format. While the Ethereum Foundation’s post-quantum team views account abstraction and execution-layer verification as its primary roadmap, validator-level signature updates represent a separate technological hurdle from migrating user-controlled balances.
Hardware Implementations and Legacy Account Constraints
Hardware infrastructure providers are also establishing foundational tooling for developers. Ledger has integrated Module-Lattice-Based Digital Signature Algorithm (ML-DSA) capabilities into its software development kit (SDK). While this supplies signing machinery to developers, hardware library updates do not modify the validation parameters or signature standards accepted by the Bitcoin or Ethereum main networks.
Crucially, transitioning existing Ethereum accounts presents persistent backward-compatibility challenges. Simply appending smart contract logic to an existing Externally Owned Account (EOA) does not eliminate its classical signature vulnerabilities. Under delegation mechanisms such as EIP-7702, a signature from the account’s original private key can override, clear, or update the delegated contract code, while the underlying account still retains the capability to authorize ordinary, classical transactions directly.
Why This Matters
The distinction between publishing a cryptographic specification and altering consensus rules is critical for distributed systems. Mitigating quantum risk requires a coordinated pipeline involving mathematical specifications, cryptographic hardware capabilities, client software validation engines, and consumer wallet integration.
While experimental contracts and draft BIPs confirm active preparation across open-source communities, neither network has deployed active mainnet rules that eliminate elliptic-curve cryptography for active spenders. The current transition period demonstrates that post-quantum resilience will require multi-stage upgrades: first concealing public keys at rest, then deploying post-quantum signature verification at scale, and finally retiring legacy execution pathways entirely.
Frequently Asked Questions
Does BIP-360 introduce post-quantum signatures to Bitcoin?
No. BIP-360 proposes Pay-to-Merkle-Root (P2MR) to remove Taproot’s key-path spend and conceal exposed public keys over long periods. It explicitly does not introduce post-quantum signature algorithms or defend keys exposed in the mempool during the broadcast window prior to block confirmation.
Can Ethereum smart contracts already verify post-quantum signatures?
Yes. Because the Ethereum Virtual Machine allows developers to write custom verification logic, schemes like SPHINCS+ can run inside standard smart contracts. However, protocol-level upgrades like EIP-8141 frame transactions remain drafts tested on development networks and are not yet supported by standard node clients such as Geth v1.17.9.
Does adding post-quantum logic to an existing Ethereum wallet eliminate elliptic-curve vulnerability?
Not necessarily. For standard Externally Owned Accounts (EOAs), delegating authority via mechanisms like EIP-7702 does not retire the original classical key. The original key can still broadcast standard transactions or overwrite the delegated account logic at any time.
