Executive summary
Blockchain and Web3 systems face a post-quantum cryptography challenge that is architecturally different from every other enterprise environment. In most infrastructures, Harvest Now, Decrypt Later is a passive collection risk — adversaries capture encrypted traffic today and decrypt it when a cryptographically relevant quantum computer arrives. For blockchain, the harvest is not a collection activity. It is a design feature.
Every public blockchain address that has ever transacted has already published its public key to a permanent, immutable, adversary-readable ledger. Every Bitcoin address that has ever spent, every Ethereum account that has ever sent a transaction, every Solana wallet that has ever signed a message, every Cosmos validator that has ever produced a block — the corresponding public keys are already in the adversary's collection. Not because the adversary tapped a fiber. Because the ledger published them by design.
This single fact makes blockchain PQC migration different from every other environment. The Cloud, IT, OT, and AI surfaces described in earlier whitepapers in this series involve migrating cryptography that adversaries are still working to collect. The blockchain surface involves cryptography whose public keys have already been collected. The clock is not counting down toward harvest completion. It is counting down toward decryption.
This whitepaper defines the four cryptographic surfaces of blockchain and Web3, explains why pre-launch is the only clean migration path for any new chain or application, describes how blockchain intersects the Cloud, IT, and application-layer surfaces enterprise CISOs already govern, and outlines the operating model for running PQC migration on a blockchain application before it goes live.
For any blockchain application currently in pre-launch — any new chain, any new rollup, any new bridge, any new Web3 application — the design decision to build with post-quantum cryptography from day one is dramatically cheaper than the coordinated community upgrade that will be required after launch. Every classical signature scheme deployed to production is an asset with a defined shelf life. Every public key published to the ledger is a harvest already complete. The right time to migrate is before the launch. The second-best time is now.
Act 1: The harvest is already complete
Start with the strongest fact about blockchain PQC — the fact that most non-blockchain audiences have never had explained to them, and that many blockchain audiences have not confronted the operational implications of.
Every public blockchain address is a public key, or a hash of one. On Bitcoin, an address is typically the hash of a public key until the moment the address spends — and the moment it spends, the public key is published to the blockchain as part of the transaction signature. On Ethereum, the address is a truncated hash of the public key, and every transaction the address sends publishes the public key in the transaction envelope. On Solana, on Cosmos, on Polygon, on every major public chain, the same pattern holds: the public key becomes visible on chain as soon as the address transacts.
This means an adversary interested in harvesting blockchain public keys does not need to run passive network capture at internet backbone tap points. The adversary runs a full node. The public keys are already indexed by every block explorer. Every public key on every public chain is queryable in real time by any adversary with a laptop and an internet connection.
The scale of what has already been harvested is staggering. Bitcoin has over one billion transactions in its history. Ethereum has over two billion. Every one of them published a public key. Add every Solana transaction, every Cosmos SDK chain, every Polygon transaction, every Layer 2 rollup transaction, every cross-chain bridge transaction, and the total number of quantum-vulnerable public keys already in adversary collection is measured in tens of billions.
When a cryptographically relevant quantum computer arrives, the adversary does not need to decide which harvested keys to prioritize. They can run Shor's algorithm against every public key that has ever appeared on any public chain. The private keys become derivable. The wallets become drainable. The bridges become forgeable. The governance votes become injectable. Every historical transaction whose corresponding address is still holding value becomes a target.
The security assumption underlying every public blockchain today is that classical elliptic curve cryptography will remain unbreakable within the useful lifetime of the chain. That assumption was defensible when Bitcoin launched in 2009. It is not defensible in 2026. The lifetime of a public chain is indefinite. The lifetime of classical elliptic curve cryptography is not.
Act 2: The four cryptographic surfaces of blockchain
Blockchain systems have four distinct cryptographic surfaces. Each has its own migration challenge, its own gating factors, and its own consequences of not migrating in time.
Consensus signatures
Every block on every proof-of-stake and proof-of-work chain is signed. The signature schemes are quantum-vulnerable. Bitcoin uses ECDSA with the secp256k1 curve. Ethereum's execution layer uses the same. Ethereum's consensus layer uses BLS signatures on the BLS12-381 curve. Solana uses Ed25519. Cosmos SDK chains use Ed25519. Polkadot uses Sr25519. Every one of these signature schemes is breakable by a sufficiently capable quantum computer.
Migrating the consensus signature scheme is the deepest and most disruptive form of blockchain PQC migration. It requires a coordinated hard fork of the entire protocol. Every validator must upgrade simultaneously. Every wallet, every exchange, every block explorer, every downstream integration must upgrade with them. The political complexity of coordinating a hard fork on a major public chain is documented — Bitcoin's SegWit adoption took years, Ethereum's Merge took half a decade of preparation, and both are considered engineering successes precisely because of how difficult they were.
The candidate PQC replacements are known. NIST FIPS 204 (ML-DSA) is a lattice-based signature scheme with reasonable performance characteristics. NIST FIPS 205 (SLH-DSA) is a hash-based signature scheme with conservative security assumptions. FALCON is a NIST-selected lattice-based signature with smaller signature sizes. Each has trade-offs in signature size, verification cost, and key size that matter enormously for blockchain applications where every byte on chain has permanent cost.
Wallet key management
Every wallet on every chain manages private keys corresponding to public keys that have been published to the ledger. The public key exposure is complete for any address that has ever transacted.
The mitigation strategies available today are limited and imperfect. Wallets that never spend from an address preserve the public key hash abstraction and only expose the hash, not the full key. This is why Bitcoin best practice recommends never reusing addresses — the moment you spend, you publish. Hierarchical deterministic wallets partially mitigate the problem by generating fresh addresses for each transaction, but every generated address that ever spends still publishes its public key.
For addresses that have already transacted, the exposure is permanent. The public key is on chain. The historical harvest is already complete for that address. The only defense is to move funds to fresh addresses generated with PQC-compatible key derivation before the CRQC arrives — which requires that the wallet software, the chain, and the receiving parties all support PQC.
The candidate PQC wallet architectures are still emerging. Post-quantum key derivation, PQC-compatible hierarchical deterministic wallets, and hybrid classical + PQC signature schemes are active areas of research but are not standardized. Wallets that want to be PQC-ready today have to make architectural bets on protocols that have not yet stabilized.
Smart contract cryptography
Smart contracts perform cryptographic operations far beyond simple signature verification. They verify cross-chain messages using bridge protocols. They authenticate oracle price feeds using signature aggregation. They validate zero-knowledge proofs using elliptic curve pairings. They enforce access control using signature-based authorization schemes.
Every one of these operations uses classical elliptic curve cryptography. BLS signatures over BN254 or BLS12-381 are used in Ethereum precompiles, ZK rollup validity proofs, and consensus signatures. KZG polynomial commitments are used in EIP-4844 blob data availability. Groth16 SNARKs are used in most ZK rollups. Every one of these primitives is quantum-vulnerable.
Migrating smart contract cryptography is a per-contract migration problem multiplied by the number of contracts on every chain. Each contract that performs classical cryptography must be redeployed with PQC alternatives. Since smart contract code is typically immutable once deployed, migration requires either upgrade proxy patterns, which introduce their own risks, or wholesale replacement of the contract, which requires migrating all associated state and coordinating with every downstream user.
The candidate PQC alternatives for smart contract cryptography are underdeveloped. Lattice-based zero-knowledge proof systems are active research but not production-ready. Post-quantum signature aggregation schemes exist but have not been standardized. Verifiable delay functions with post-quantum security assumptions are still theoretical. The smart contract PQC toolchain is where the blockchain community has the most work to do.
Blockchain infrastructure
Enterprise blockchain applications and Web3 services depend on infrastructure that sits above the chain itself. Wallet infrastructure providers. RPC node operators. Indexing services. Block explorers. Custodial services. Cross-chain bridges. Layer 2 sequencers. Rollup provers.
Every one of these services runs classical cryptography for its own operations — TLS for API endpoints, mTLS for validator communications, signed messages between services, KMS-protected private keys for custody, and so on. This is the surface where blockchain infrastructure most closely resembles traditional enterprise IT and cloud infrastructure, and it is the surface where existing PQC migration guidance applies most directly.
For blockchain infrastructure, the migration path is the same as for any Cloud and IT surface: inventory the cryptographic dependencies, prioritize by exposure and consequence, migrate to PQC-capable alternatives on the vendor and standards timeline. The difference is that blockchain infrastructure sits above chains that have their own PQC migration timelines, and the infrastructure providers must plan their migration alongside the chains they support.
Act 3: Why pre-launch is the only clean migration path
The asymmetry between pre-launch and post-launch blockchain PQC migration is not incremental. It is categorical.
Pre-launch migration is a design decision. A new chain, a new rollup, a new bridge, a new Web3 application that has not yet gone live can choose its consensus signature scheme, its wallet architecture, its smart contract cryptographic primitives, and its infrastructure PQC posture as part of its initial design. The choices propagate through the codebase, through the wallet specifications, through the exchange integrations, through the tooling ecosystem, before any user has adopted the chain and before any value is at stake. The design cost is bounded. The community coordination cost is zero because there is no community yet.
Post-launch migration is a coordinated community upgrade. Once a chain is live, migrating its consensus signature scheme requires a hard fork. Every validator, every wallet, every exchange, every block explorer, every integration must coordinate the upgrade simultaneously. Users must migrate their funds from classical addresses to PQC addresses, which requires that every recipient party support PQC addresses. Smart contract migration requires either coordinated upgrade proxies for every affected contract or wholesale contract replacement with state migration. The infrastructure ecosystem — RPC providers, indexers, block explorers, custody services — must upgrade in lockstep.
The engineering complexity of a post-launch PQC migration for a major public chain has no precedent. Even Bitcoin's SegWit adoption, which was a relatively contained upgrade compared to a signature scheme migration, took years of political debate and years of ecosystem coordination. An Ethereum-wide migration from ECDSA and BLS to PQC alternatives is difficult to imagine happening in less than a decade of preparation. And that timeline assumes the community begins seriously planning it now.
For any blockchain application currently in pre-launch, the calculus is unambiguous. Building with PQC from day one costs a bounded amount of engineering work at design time. Building with classical crypto and migrating later costs an unbounded amount of engineering work at hard fork time, plus the security exposure of every user's funds during the migration window, plus the reputational cost of having built on a foundation with a known expiration date.
The permanent lesson from every major blockchain security incident is that cryptographic decisions made at launch propagate forward permanently. Address formats, signature schemes, precompile contracts, curve parameters — every one of these choices made at genesis persists for the lifetime of the chain. A chain that launches with classical elliptic curve cryptography in 2026 has committed to running on quantum-vulnerable cryptographic foundations until it hard-forks. That hard fork will happen. The only question is whether it happens on the schedule the founders chose or on the schedule the CRQC forces.
Act 4: Where blockchain intersects Cloud, IT, and enterprise applications
Enterprise blockchain applications are not just chain code. They run on cloud infrastructure. They integrate with enterprise identity systems. They connect to Web2 backends. They handle regulated data. They fall under the same cryptographic governance frameworks as every other enterprise application.
An enterprise deploying a blockchain application has cryptographic surfaces at every layer of the stack:
- Cloud infrastructure — the workloads that run the application backend, the KMS-protected wallet keys, the API gateways that broker chain interactions, the confidential compute enclaves that host signing services
- Identity and access — the enterprise identity systems that authenticate users into the application, the machine identities that authenticate services to the blockchain, the certificates that protect service-to-service communication
- Web2 backend integration — the databases, message queues, and API endpoints that connect the blockchain application to the rest of the enterprise
- The blockchain surface itself — the chain's consensus cryptography, the wallet key management, the smart contract cryptography, the bridge and oracle integrations
- Compliance and audit — the cryptographic evidence trail required by regulators for any application that handles regulated data on chain
The Full Stack PQC migration framework established in the earlier whitepapers in this series applies directly to enterprise blockchain applications. The four environments — Cloud, IT, OT, and AI — are the general framework. Blockchain becomes a fifth environment layered on top for enterprises that build or use blockchain applications. The dashboard that shows unified cryptographic posture across Cloud, IT, OT, and AI extends naturally to include blockchain-specific cryptographic surfaces alongside them.
The critical operational insight is that an enterprise cannot govern its blockchain application's PQC posture in isolation from the rest of its infrastructure. The wallet keys live in cloud KMS. The user authentication runs through enterprise identity. The API endpoints traverse the same enterprise network. The regulatory reporting flows into the same compliance framework. Blockchain PQC migration is not a separate program from enterprise PQC migration. It is a specialized subset of it.
For enterprises building blockchain applications today, this has a specific implication: the blockchain application should be included in the enterprise's Cloud, IT, OT, and AI PQC visibility dashboard from the moment the application is in pre-launch. Not later. Not when the application scales. Not when the regulator asks. From day one.
Act 5: What ArcQubit brings to blockchain PQC migration
ArcQubit's Full Stack PQC migration approach was designed for critical infrastructure enterprises across all sixteen CISA sectors and any AI-forward enterprise. The same approach extends naturally to blockchain and Web3 organizations building applications that must operate through the quantum transition.
QuTrust delivers the Full Stack PQC migration dashboard for the blockchain application. The dashboard hosts the living migration roadmap and generates the Quantum Exposure Report — the live cryptographic inventory that answers, on demand, what the current PQC posture is for every asset in the application across Cloud, IT, application-layer, and blockchain surfaces.
For a pre-launch blockchain application, the value of the dashboard is different in character from a post-launch enterprise migration. Pre-launch, the dashboard is a design tool. It maps the cryptographic exposure of the architecture as it is being built. It highlights the classical signature schemes, the classical key management, the classical bridge protocols that are being deployed. It gives the engineering team the visibility to make PQC design decisions before the code ships, when those decisions are still cheap.
For a post-launch blockchain application, the dashboard is a migration tool. It maps the existing cryptographic exposure across cloud infrastructure, wallet management, smart contract cryptography, and infrastructure services. It prioritizes migration actions using the same three-axis scoring model — quantum exposure, data sensitivity, and migration ease — that governs all other Full Stack migrations. It generates the executive reporting that boards, regulators, insurers, and audit committees require.
Across both pre-launch and post-launch, the dashboard's function is the same: unify the cryptographic posture of the application across every layer of its architecture, present it in one report the CISO or founder can defend to any audience, and produce the prioritized roadmap that translates current posture into forward-moving migration work.
QuTrust does not decide the migration strategy. The blockchain team decides. QuTrust does not choose the PQC signature scheme. The team chooses. QuTrust does not fork the chain. Only the community can do that. QuTrust delivers the visibility, the prioritization, and the evidence that make the migration executable — pre-launch as a design constraint or post-launch as a coordinated program.
Coda: The permanent question
Every blockchain application launching today has to answer one question that no application built in Web2 had to answer:
Will my cryptographic foundations still be defensible in the twenty-year lifetime of my chain?
For a Web2 application, this question does not apply. Web2 applications retire and get replaced. Their cryptographic foundations migrate with them. A Web2 API launched in 2016 with TLS 1.2 has been migrated to TLS 1.3 in the years since, and will be migrated to hybrid PQC TLS in the years to come, without any user ever knowing the transition happened.
Blockchain is different. The chain does not retire. The addresses do not migrate. The historical transactions do not un-publish their public keys. Every cryptographic decision made at launch persists in the immutable record forever.
An enterprise deploying a Web2 application built with classical cryptography can shrug off the PQC migration timeline as a general infrastructure problem to be solved over the next decade. A protocol team launching a blockchain application built with classical cryptography is committing to a specific hard fork sometime before the CRQC arrives, or accepting that every wallet and every bridge and every smart contract they ship will be drainable by a quantum-capable adversary within the useful lifetime of the chain.
The right answer to the permanent question is to build the cryptographic foundations to withstand the twenty-year horizon at launch. That is the design discipline ArcQubit exists to support. That is why the pilot ArcQubit is launching with a blockchain company that has state-of-the-art applications is the right kind of engagement at the right kind of moment — pre-launch, when the design decisions can still be made cheaply, when the community coordination cost is zero, and when the resulting application can go live with quantum resilience built in from day one.
The ledger is already harvested. The question is what happens after the CRQC arrives. Every classical signature on the chain becomes forgeable. Every classical wallet becomes drainable. Every classical bridge becomes exploitable. Every classical smart contract becomes untrustable. This is the future the chain must survive.
The blockchain applications that build on post-quantum cryptography from day one will survive it. The blockchain applications that do not will spend their working lifetimes racing a clock they did not know had already been running.
Pre-launch is the right time to fix crypto debt. Not after.