The flaw is not in the timeline estimate. The flaw is in the assumption that a migration is possible at all — that a live blockchain with hundreds of millions of classical-key accounts, years of signed transaction history, and no mechanism for retroactive key replacement can execute a clean post-quantum transition when the time comes. It cannot. The migration is not hard. For a public ledger, it is structurally incoherent.

This is why we built Quantova without classical keys from the first block.

The Archive Problem

A public blockchain is a permanent, publicly accessible record of every transaction ever signed. Unlike a database that can be selectively updated or encrypted communications that can be rekeyed, a blockchain's history cannot be modified. Every signature ever produced is on-chain, forever.

This matters because of harvest-now-decrypt-later. An adversary does not need to break elliptic curve cryptography today. They need only archive the chain — which is free, automated, and already happening — and wait. When quantum hardware matures to the point where ECDSA becomes breakable, every signature ever produced on every classical blockchain becomes retrospectively readable.

What does a broken signature enable? Address linkage. Key recovery. The ability to reconstruct which addresses a party controlled at what time, regardless of the privacy measures they took when the transaction was made. For infrastructure built to settle high-value institutional transactions or store long-horizon financial records, this is not a theoretical risk. It is a scheduled one.

The INRIA cryptography group estimated in 2026 that breaking 256-bit elliptic curve cryptography requires approximately 1,193 logical qubits — a 44% reduction from prior estimates. The US National Security Agency has set a 2030 deadline for migration to post-quantum standards under CNSA 2.0. The US National Institute of Standards and Technology finalised its first post-quantum cryptography standards in 2024 following an eight-year evaluation process.

These are not speculative projections. They are institutional planning parameters.

Why Migration Is the Wrong Frame

The standard response to the quantum argument is: we will migrate when we need to. This sounds reasonable until you examine what migration actually requires for a live public blockchain.

Every existing account holds a key pair. In a post-quantum migration, every one of those accounts needs to generate a new post-quantum key pair, produce a migration transaction signed by both the old classical key and the new post-quantum key, and broadcast that transaction on-chain before quantum hardware becomes capable of breaking the classical key. If any account fails to migrate — dormant wallets, lost keys, institutionally held accounts that no longer have active signatories — that account becomes vulnerable, and its assets become recoverable by whoever first acquires the quantum capability to break the key.

At scale, this coordination problem has no clean solution. You cannot force every address to migrate. You cannot invalidate unmigrated accounts without destroying holdings. You cannot make the transition atomic across a decentralised network. And you cannot migrate the historical record — the signed transactions that predate the migration are already on-chain and stay there.

A network that launches today on classical cryptography is not building towards a quantum-safe future. It is building a larger archive of classical-key data that will require an impossible coordination event to partially address, at some point when the pressure to do so is already acute.

What Genesis-Level Post-Quantum Actually Means

Quantova has no classical keys anywhere in the protocol. Not a migration path, not a parallel classical layer, not an optional post-quantum mode. The protocol was specified from the first block with no secp256k1 key pairs, no ECDSA signatures, and no elliptic-curve operations in any path that matters.

At the account layer, three NIST-standardised signature schemes are supported: Dilithium (ML-DSA, FIPS 204), Falcon (FN-DSA), and SPHINCS+ (SLH-DSA, FIPS 205). Every transaction is wrapped in a QSignature envelope that carries the variant byte, the post-quantum signature, and the corresponding public key. Account addresses are derived from SHA3-256 hashes of post-quantum public keys, with a designated prefix byte marking the address space.

Validator consensus runs on Falcon-512 keys. Threshold encryption for private data uses ML-KEM-768 (FIPS 203). The smart contract execution environment, QVM, enforces the network's cryptographic policy at the runtime layer — contracts inherit the security model of the network rather than managing their own key assumptions.

There is no path by which an account on Quantova is ever signed with a classical key. This is not a feature. It is the architecture.

The Bridge Layer Extends the Argument

A post-quantum Layer-1 that connects to the broader ecosystem via classically signed bridge attestations has partially solved the problem. The on-chain state is quantum-resistant; the cross-chain messages are not.

Quantova's cross-chain bridge enforces post-quantum signing on the Quantova side in all configurations — regardless of the verification mechanism used for the connected chain. Whether a settlement is gated on a Bitcoin SPV Merkle proof, an Ethereum sync-committee BLS attestation, or a federated relayer quorum for a chain that doesn't yet support trustless verification, the message that Quantova signs to finalise that settlement is post-quantum signed.

This matters for the same reason the on-chain signatures matter: bridge settlement messages are high-value, time-stamped, and permanently recorded. They are the most natural target in any infrastructure archive. Signing them with classical keys defeats the purpose of a post-quantum network.

The bridge currently spans 36 chains and 68 assets across three verification tiers. Trustless verification — SPV and light-client — is used wherever the connected chain's protocol supports it. Federated verification is used where it does not, with the trust model documented explicitly.

Where We Are

The Quantova public testnet is live. The protocol is in a controlled testing phase ahead of mainnet. A pre-audit has been completed; an independent external security audit is in progress.

Source-available code and technical documentation are at quantova.org. The bridge specification and pallet implementations are public in the Quantova GitHub repository.

We are not making predictions about quantum timelines. We are building infrastructure that does not need to.

Quantova is a post-quantum Layer-1 blockchain network. This publication covers protocol architecture, development updates, and research relevant to quantum-resistant blockchain infrastructure.