Quantum-safe accounts for the blockchains you use today
Shor's algorithm, run on a large enough quantum computer, breaks the elliptic-curve signatures behind every Bitcoin and Ethereum account. That computer does not exist yet, but every account that has signed a transaction has already published the public key an attacker would need. Instanodes offers hybrid quantum-safe accounts for EVM smart accounts, independent of any chain's own upgrade timeline. Talk to us to set one up.
- Logical qubits
- <1,200
- Google Quantum AI's 2026 estimate for breaking 256-bit elliptic-curve keys, needing about 20x fewer physical qubits than earlier estimates.
- Flagged risk horizon
- Before 2028
- The earliest window Vitalik Buterin has publicly flagged for a quantum break of elliptic-curve cryptography.
- NIST disallows ECDSA
- By 2035
- NIST IR 8547 deprecates 112-bit ECDSA and RSA after 2030 and disallows all quantum-vulnerable signatures after 2035.
- On-chain key exposure
- Permanent
- Once an account signs a transaction, its public key stays on-chain. It cannot be withdrawn.
SourcesGoogle Quantum AI, March 2026Vitalik Buterin at Devconnect 2025, via CointelegraphNIST IR 8547 (initial public draft)
Where each chain stands on post-quantum signatures
Every ecosystem is moving toward post-quantum security on its own path and timeline. On Ethereum and EVM L2s, you can protect accounts before any protocol upgrade lands.
| Chain | Signs with | Post-quantum path | Status |
|---|---|---|---|
 EthereumL1 | ECDSA secp256k1; BLS for validators | EIP-8141 (frame transactions) would let any account validate with its own signature scheme, post-quantum included. The Ethereum Foundation is researching hash-based signatures for consensus. | Draft proposal |
 BitcoinL1 | ECDSA and Schnorr, secp256k1 | BIP-360 proposes a quantum-resistant output type; BIP-361 proposes a phased sunset of legacy signatures. Either needs a soft fork. | Proposed |
 SolanaL1 | Ed25519 | Ed25519 falls to Shor's algorithm like secp256k1. Opt-in hash-based (Winternitz) vault programs exist; no network-wide migration is scheduled. | Opt-in vaults |
 AvalancheL1 | ECDSA secp256k1; BLS for validators | Transactions and validator Warp messages both use elliptic-curve schemes. No network-wide post-quantum migration is scheduled. | No migration scheduled |
 CardanoL1 | Ed25519 | Wallet and stake-pool keys use Ed25519. IOG has published research on post-quantum alternatives, with no production timeline set. | Research |
   EVM L2sLayer 2 | ECDSA secp256k1 | Smart accounts verify signatures in contract code, so a post-quantum scheme works today without a base-layer upgrade, at a higher gas cost. | Available via smart accounts |
- EthereumL1
- Signs with
- ECDSA secp256k1; BLS for validators
- Post-quantum path
- EIP-8141 (frame transactions) would let any account validate with its own signature scheme, post-quantum included. The Ethereum Foundation is researching hash-based signatures for consensus.
- Status
- Draft proposal
- BitcoinL1
- Signs with
- ECDSA and Schnorr, secp256k1
- Post-quantum path
- BIP-360 proposes a quantum-resistant output type; BIP-361 proposes a phased sunset of legacy signatures. Either needs a soft fork.
- Status
- Proposed
- SolanaL1
- Signs with
- Ed25519
- Post-quantum path
- Ed25519 falls to Shor's algorithm like secp256k1. Opt-in hash-based (Winternitz) vault programs exist; no network-wide migration is scheduled.
- Status
- Opt-in vaults
- AvalancheL1
- Signs with
- ECDSA secp256k1; BLS for validators
- Post-quantum path
- Transactions and validator Warp messages both use elliptic-curve schemes. No network-wide post-quantum migration is scheduled.
- Status
- No migration scheduled
- CardanoL1
- Signs with
- Ed25519
- Post-quantum path
- Wallet and stake-pool keys use Ed25519. IOG has published research on post-quantum alternatives, with no production timeline set.
- Status
- Research
- EVM L2sLayer 2
- Signs with
- ECDSA secp256k1
- Post-quantum path
- Smart accounts verify signatures in contract code, so a post-quantum scheme works today without a base-layer upgrade, at a higher gas cost.
- Status
- Available via smart accounts
Hybrid post-quantum signing, deployable today
Built in the direction of the Ethereum Foundation's published post-quantum research. This is new cryptography without decades of field use, and we say so to every team we work with; each deployment is designed so a future scheme swap never needs a new address.
Hybrid signing
Two signatures on every transaction
Each transaction is signed with your existing ECDSA key and a post-quantum key. The account accepts it only if both verify, so breaking one scheme is not enough.
Separate recovery
Recovery on a different key family
Daily signing uses lattice-based cryptography, the family behind ML-DSA (FIPS 204). Cold recovery uses hash-based signatures, the family behind SLH-DSA (FIPS 205). A break in one path does not reach the other.
Account abstraction
Deploys on Ethereum and EVM L2s now
The account is a smart contract, so it runs on Ethereum and EVM L2s today. It needs no hard fork and does not wait on any chain's own migration timeline.
Modular validation
Swap schemes without a new address
Signature validation is a module. As precompiles and proof aggregation mature, a cheaper or stronger scheme installs in place and the account keeps its address.
Quantum risk, in plain terms
Need something specific? Talk to an engineer.
Not today. Breaking 256-bit elliptic-curve keys still needs quantum hardware far beyond anything that exists, though published resource estimates keep falling. The risk is asymmetric: unlike "harvest now, decrypt later" attacks on encrypted traffic, nothing needs harvesting, because exposed public keys already sit on-chain. The day a capable quantum computer exists, those keys can be turned into forged signatures. That is why teams migrate early, even though a break is not imminent.
Signing a transaction publishes your public key on-chain for good, on Ethereum and on Bitcoin. That exposure cannot be undone. The protection is to move funds to a quantum-safe account before a capable quantum computer arrives. An Ethereum address that has only received funds has not exposed its key yet, which buys time but is no long-term fix. On Bitcoin, Taproot and legacy pay-to-public-key outputs expose the key as soon as they are created.
Not on Ethereum. Ethereum and EVM L2s support account abstraction, so a smart contract account can verify a post-quantum signature today without a protocol-wide hard fork. Bitcoin is more constrained: base-layer support needs a soft fork, so until a proposal such as BIP-360 activates, the practical defence is key hygiene: never reuse addresses and keep funds in outputs that do not expose a public key.
It depends on the proof system. STARKs rely on hash functions and are considered quantum-resistant. SNARKs such as Groth16 and KZG-based PLONK rely on elliptic-curve pairings, so they are not. Many rollups wrap a STARK prover in a SNARK for cheaper on-chain verification, and that final step brings the elliptic-curve weakness back.
More than ECDSA, which the EVM checks through the ecrecover precompile for 3,000 gas. A post-quantum signature is verified in contract code instead, and costs many times that. Hash-based schemes tuned for the EVM are the cheapest option today. The premium should fall as dedicated precompiles and proof aggregation mature.
Start migrating before migration is mandatory.
Talk to an engineer about a hybrid quantum-safe account rollout for your chain, wallet or protocol, before a hard fork sets the timeline for you.