Introduction: Two Ways to Become Quantum-Resistant
There are two ways for a blockchain network to become quantum-resistant. The first is to migrate: take a network built on classical cryptography and upgrade its cryptographic layer to post-quantum algorithms. The second is genesis design: build the network on post-quantum cryptography from the first block, so there is nothing to migrate.
The migration approach is what Ethereum, Bitcoin, Stellar, and every other major network must pursue. It is an enormous, multi-year, multi-phase coordination challenge involving hundreds of millions of accounts, thousands of validator operators, and a global ecosystem of wallets, exchanges, custodians, and application developers all of whom need to move simultaneously, or in a carefully managed sequence, or face a period of mixed-security operation.
The genesis approach is what Quantova has done. This article explains why that distinction is not merely a talking point it is a fundamental difference in the security, complexity, and long-term trajectory of the two systems.
The Migration Problem: Why Retrofitting Is Hard
The Dormant Account Problem
Every blockchain network accumulates dormant accounts addresses that hold funds but whose owners are unreachable, deceased, or simply no longer active. On Bitcoin, analyses suggest millions of BTC sit in addresses that have not moved in years. On Ethereum, a similar distribution exists.
When a network decides to deprecate classical cryptographic keys in favour of post-quantum alternatives, it faces an unavoidable question: what happens to dormant accounts whose owners cannot be reached to perform the migration? If the network enforces a cutover date, those accounts may be permanently frozen. If the network allows classical keys to remain valid indefinitely, the security upgrade is incomplete.
Stellar’s Quantum Preparedness Plan, published in June 2026, acknowledges this problem explicitly and states it will require community discussion before a resolution is proposed. There is no clean answer. On Quantova, this problem does not exist. Every account on the network was created with a post-quantum key from genesis. There are no classical keys to migrate away from.
The Coordination Problem
Even for accounts whose owners are reachable, migration requires coordination at a scale no blockchain network has ever executed. Users must be informed, wallets must be updated, exchanges must update their signing infrastructure, custodians must update their key management systems, smart contracts that rely on signature verification must be audited and potentially redeployed.
Each chain’s migration has a different shape, but all share the same underlying complexity: retrofitting post-quantum cryptography onto millions of existing accounts in a live, production network without disrupting the people who depend on it.
The Harvest-Now-Decrypt-Later Problem
Adversaries with sufficient resources are already collecting on-chain data not because they can decrypt it today, but because they intend to when quantum hardware reaches sufficient capability. Reused Bitcoin addresses have already published their public keys on-chain. Every block explorer has this data. When quantum hardware arrives, those public keys become the input to Shor’s algorithm. Migration plans that extend over years must grapple with the possibility that quantum hardware arrives before the migration is complete.
What Post-Quantum From Genesis Actually Means
“Post-quantum from genesis” is a specific architectural claim, not a general marketing statement. It means that every cryptographic operation in the protocol from the moment the first block was produced uses algorithms whose security does not rely on the mathematical problems quantum computers can solve efficiently.
On Quantova, every account holds a post-quantum key pair Dilithium, Falcon, or SPHINCS, all standardised by NIST. There are no secp256k1 or Ed25519 keys in the account layer. Addresses are derived from SHA3-256 of the public key a hash function, not a direct encoding meaning the public key is not exposed on-chain before a transaction is signed. Validator nodes sign consensus messages with Falcon-512. Threshold encryption uses ML-KEM-768 (NIST FIPS 203), not BLS12-381. Cross-chain bridges are secured by post-quantum keys on the Quantova side. None of these are retrofits. They are the default state of the network from block one.
The Scheme-Agnostic Address Model: Future-Proofing Beyond Today’s Standards
Post-quantum cryptography is not a solved problem. Research continues. New algorithms will be proposed, evaluated, and potentially standardised. Some of today’s post-quantum algorithms may be found to have weaknesses that current analysis has not identified.
Quantova’s account model is designed for this reality. Because addresses are derived from a hash of the public key not from the key material itself the address format is independent of the signature scheme. Adding a new post-quantum signature scheme to the network does not require changing the address format. Users can switch between schemes, or adopt new schemes as they are added, without changing their address. Algorithm transitions are a key-layer operation, not an address-layer operation structurally simpler and less disruptive by design.
The Industry Context: Why the Timing of This Matters
In the first half of 2026, several developments converged to accelerate the quantum security conversation in blockchain. INRIA researchers published estimates suggesting that breaking 256-bit elliptic curve cryptography requires approximately 1,193 logical qubits a 44% reduction from prior estimates. NIST updated its guidance to place the danger window at 2029 and beyond. Google set 2029 as its internal post-quantum readiness deadline.
Simultaneously, a Coinbase-backed report estimated that up to 7 million Bitcoin may be vulnerable to future quantum attacks. Stellar published a three-stage quantum preparedness plan. Ethereum researchers proposed SPHINCS- as a low-cost interim measure for account-level quantum protection. The industry is not ignoring quantum risk. It is beginning to confront, in public, the scale of what migration represents.
Quantova was built in the context of this challenge not as a response to it, but as a demonstration that the challenge can be avoided entirely if the cryptographic foundation is right from the start.
Summary
Post-quantum from genesis means no dormant account problem, no coordination overhead for migration, no harvest-now-decrypt-later exposure on existing accounts, and no future migration event when the quantum threat materialises. Quantova implements NIST-standardised post-quantum algorithms Dilithium, Falcon, SPHINCS+, ML-KEM-768 across every layer of the protocol. The address model is scheme-agnostic, meaning new post-quantum algorithms can be added as the field evolves without changing how accounts or applications work. Full technical documentation is available at quantova.org and github.com/Quantova.
