A post-quantum blockchain uses cryptography designed to resist known quantum attacks.
Adopting post-quantum cryptography can require changes to how a blockchain approves transactions, how wallets manage keys, and how nodes communicate.
What Does “Post-Quantum” Mean?
“Post-quantum” refers to security designed for a future in which quantum computers are powerful enough to break widely used public-key cryptography. That includes methods used to authorize crypto transactions and establish secure internet connections.
Post-quantum cryptography, or PQC, uses mathematical problems believed to remain difficult for both conventional and quantum computers to solve. Developers can use these algorithms on ordinary computers today, including the devices that run wallets and blockchain nodes.
The phrase “post-quantum blockchain” therefore needs context. To understand the protection a chain offers, we need to know which parts use post-quantum cryptography and whether that protection applies to the assets and accounts people already use.
What Is Cryptography, and How Does a Blockchain Use It?
Cryptography uses mathematical methods to protect information and verify its authenticity. In a blockchain, it helps computers check who authorized a transaction and whether recorded data has changed.
Digital Signatures: Authorizing Your Transaction
When you send crypto, your wallet uses your private key to create a digital signature for the transaction. The computers checking it, called nodes, use the matching public key to verify that signature without learning your private key.
A signature protects the transaction details it covers. For a typical transfer, these include the recipient and amount; changing those signed details causes verification to fail.
A sufficiently capable quantum computer could threaten commonly used signature schemes by deriving a private key from its public key. An attacker could then sign transactions using that recovered key.
Key Establishment and Encryption: Protecting Connections
When your wallet connects to a service over an encrypted connection, the two systems need a shared secret to protect the messages they exchange. Key establishment is the process that lets them establish that secret across a public network.
Symmetric encryption then uses a shared secret key to encrypt and decrypt the messages. The connection needs both steps: a secure way to establish the key and a secure way to use it.
These methods protect communication between systems. Transactions recorded on a public blockchain generally remain publicly visible.
Hashing: Detecting Changes to Data
A hash function converts data into a fixed-length value called a hash. Changing the input, even slightly, normally produces a different result.
Blockchains use hashes to check transaction data and connect blocks to their history. If someone changes a recorded transaction, its hash changes too, allowing other computers to detect the mismatch against the accepted record.
Hashing is also used inside some post-quantum signature schemes. Its role and required security depend on how the blockchain uses it.
How Does Quantum Computing Affect Each Method?
The quantum threat differs across these functions. Widely used public-key signatures and key-establishment methods require replacements, while suitable symmetric encryption and hash functions can continue to be used.
| Cryptographic function | What it does | Common examples | What post-quantum preparation involves |
|---|---|---|---|
| Digital signatures | What it doesVerifies authorization of transactions and other signed messages | Common examplesECDSA, Ed25519 | What post-quantum preparation involvesReplacing vulnerable signature schemes and supporting the new keys throughout the blockchain’s software |
| Key establishment | What it doesEstablishes a shared secret for protected communication | Common examplesElliptic-curve Diffie–Hellman | What post-quantum preparation involvesAdopting a post-quantum method such as ML-KEM within a suitable communication protocol |
| Symmetric encryption | What it doesEncrypts messages using a shared secret key | Common examplesAES | What post-quantum preparation involvesUsing an appropriate key size and ensuring the method used to establish that key is also secure |
| Hashing | What it doesHelps detect changes to data and verify blockchain records | Common examplesSHA-256, SHA-384 | What post-quantum preparation involvesReviewing the hash function, its output length, and the security requirements of each use |
What Did Google’s 2026 Research Change?
In March 2026, Google Quantum AI published research suggesting that a future quantum computer could attack the elliptic-curve cryptography used by Bitcoin with fewer resources than earlier estimates indicated.
The researchers calculated what the attack would require under specific assumptions about the computer’s hardware and error rates. Their circuit designs reduced the estimated work involved.
What is a quantum circuit?
A quantum circuit is a sequence of operations a quantum computer performs to complete a calculation. Researchers can redesign that sequence to reduce the number of quantum bits (qubits) or operations required.
The study modeled a machine that would still need to be built. Better attack methods could lower the hardware requirements before blockchains finish replacing vulnerable cryptography, giving developers another reason to begin preparation early.
Which Types of Post-Quantum Cryptography Can Blockchains Use?
Blockchain developers have several options for replacing vulnerable signatures and securing connections. These options use different mathematical problems that are believed to resist known quantum attacks.
The U.S. National Institute of Standards and Technology, or NIST, evaluates these algorithms through a public review process and publishes standards specifying how selected algorithms should work. In August 2024, it finalized three: ML-DSA and SLH-DSA for digital signatures, and ML-KEM for establishing shared secrets.
These standards represent two approaches to post-quantum cryptography: lattice-based and hash-based. A third approach, code-based cryptography, is also progressing through standardization.
Lattice-Based Cryptography: Signatures and Secure Connections
Lattice-based cryptography uses mathematical problems involving regular arrangements of points in many dimensions. The algorithms allow someone with the secret key to sign a message or establish a shared secret, while making it difficult for an attacker to recover that key from public information.
Two standardized algorithms use this approach for different purposes.
ML-DSA creates digital signatures. A blockchain can use it to authorize transactions or authenticate messages from nodes. Developed from Dilithium, ML-DSA is specified in FIPS 204.
ML-KEM establishes a shared secret between two systems. That secret can then be used to derive keys for encrypting their communication. For a blockchain, this could be part of establishing protected connections between nodes. Developed from Kyber, ML-KEM is specified in FIPS 203.
What does FIPS mean?
FIPS stands for Federal Information Processing Standards. Each numbered document specifies a standard. For example, FIPS 204 defines the ML-DSA signature algorithm and its permitted settings.
Hash-Based Cryptography: Another Approach to Signatures
Hash-based cryptography constructs digital signatures using hash functions. The same type of mathematical tool that helps detect changes to blockchain data can also be used within a signature scheme.
SLH-DSA, developed from SPHINCS+, is a hash-based signature standard published as FIPS 205. Its security depends on properties of hash functions, providing an alternative to the lattice problems used by ML-DSA.
The choice involves practical tradeoffs. SLH-DSA generally produces larger signatures and requires more time to sign than ML-DSA. That can make it less suitable for frequent transactions, while leaving it useful for applications such as signing software updates, where signing speed may be less important.
Further Reading: Next steps in preparing for post-quantum cryptography.
Code-Based Cryptography: An Alternative for Establishing Secrets
Error-correcting codes help computers recover information when data has been corrupted. Code-based cryptography uses related mathematical problems in which recovering the original information is difficult without secret knowledge.
HQC uses this approach to establish shared secrets. NIST selected it for standardization as an alternative to ML-KEM because it relies on different mathematics. Having both approaches reduces dependence on a single set of security assumptions. NIST’s selection announcement explains this reasoning.
HQC’s standard is still forthcoming in NIST’s current register, so it should be distinguished from the finalized standards above.
| Algorithm | Mathematical approach | What it is used for | Standardization status |
|---|---|---|---|
| ML-DSA | Mathematical approachLattice-based | What it is used forDigital signatures, including blockchain transaction signing where supported | Standardization statusFinal standard: FIPS 204 |
| ML-KEM | Mathematical approachLattice-based | What it is used forEstablishing shared secrets for protected connections | Standardization statusFinal standard: FIPS 203 |
| SLH-DSA | Mathematical approachHash-based | What it is used forDigital signatures, with different size and performance tradeoffs | Standardization statusFinal standard: FIPS 205 |
| HQC | Mathematical approachCode-based | What it is used forEstablishing shared secrets using different security assumptions from ML-KEM | Standardization statusSelected for standardization; standard forthcoming |
The choice depends on how frequently users and nodes sign messages, how quickly nodes must verify them, and how much data the network can transmit and store. Those requirements make key and signature sizes an important part of the decision.
The Scaling Challenge of Post-Quantum Signatures
Many post-quantum signature schemes produce substantially more data than the elliptic-curve schemes commonly used by blockchains.
For example, ML-DSA-87 produces a 4,627-byte signature, or about 4.6 kilobytes. Its public key is another 2,592 bytes, though whether that key accompanies every transaction depends on the blockchain’s design.
Across thousands of transactions, that additional data can increase bandwidth and storage requirements. If a chain keeps the same block-size limit, larger transactions can leave room for fewer transfers. Fees may also increase where the chain charges according to transaction size.
Existing blockchains have to accommodate these changes within rules and software originally designed for smaller signatures. Developers may need to revise transaction-size limits, fee calculations, and how signatures are transmitted and stored.
Developers are exploring proof-based signature aggregation to reduce this overhead. A computer checks many signatures and produces a cryptographic proof that they are valid for the corresponding transactions and public keys. Where the protocol supports this approach, a block can include the proof and compact references instead of every individual signature. The transactions themselves still need to be recorded.
Ethereum’s draft EIP-8288 proposes this approach using STARK proofs, a type of cryptographic proof that can verify many calculations together. It is a proposal for a future upgrade. Whether aggregation saves space depends on the proof system and how many signatures are combined.
The original signatures still need to be created and processed, and generating the proof requires additional computation. Developers therefore need to test the storage savings alongside processing time and hardware requirements. The proof system must also be assessed for resistance to quantum attacks.
What Has to Change in a Blockchain?
Developers first need to identify where the blockchain and its supporting software use vulnerable cryptography. The scope depends on the network’s design, but several areas need attention.
Transaction Rules and Wallets
The blockchain must recognize the new signatures and define how nodes verify them. Your wallet also needs to create, store, and back up the corresponding keys. Updating the wallet alone cannot protect a transaction if the blockchain does not accept its signature.
Signatures Used to Agree on Blocks
Some networks require validators to sign messages as they decide which blocks to accept. These signatures protect the network’s agreement process, called consensus. Where they use vulnerable cryptography, they need a transition of their own, separate from the signatures users create when sending funds.
Protected Connections
Nodes and services may use public-key cryptography to authenticate one another and establish encrypted connections. Those communication protocols need review wherever they rely on quantum-vulnerable algorithms.
Proofs and Other Cryptographic Checks
Some blockchains use proofs to verify batches of transactions or protect private information. This includes ZK-rollups, layer 2 networks that process transactions and submit proofs of their correctness to a base blockchain. Their proof systems need a separate quantum-security assessment, even if users adopt post-quantum signatures.
Others use cryptographic commitments, which let a system publish a value that binds it to particular data, then later prove that the data matches.
Each construction needs its own assessment. Ethereum’s post-quantum roadmap illustrates why account signatures, validator signatures, and data-related cryptography require separate work.
Applications and Supporting Services
Exchanges, bridges, custodians, and applications must recognize the new transaction and key formats wherever they depend on them. Otherwise, a user could have a compatible wallet but still be unable to deposit funds or interact with a service.
Stablecoin issuers also need to review the keys and permissions used to create tokens, authorize burns during redemption, and administer token contracts. Where these controls rely on vulnerable signatures, they need their own migration plan.
Existing Funds and Permissions
Users may need to move funds or replace keys that control accounts and smart contracts. The migration plan must explain how they can authorize that change securely and what happens to assets that remain under older protection.
Post-Quantum From Genesis Versus Retrofitting an Existing Blockchain
A blockchain’s first block is called its genesis block. A network designed to use post-quantum cryptography from genesis can introduce compatible transaction rules, wallets, and node software before users acquire assets on it. That avoids an initial migration from older signing keys, although the implementation still needs security testing and may require future upgrades.
An existing blockchain must introduce new cryptography while people continue using the network. If you already hold funds, the upgrade needs to preserve your ability to access them and give you a secure way to adopt the new protection.
Bitcoin: Who Moves the Coins?
Bitcoin’s migration questions extend beyond selecting a signature algorithm. Participants also need to decide how new spending rules are adopted, how holders move their funds, and whether older spending methods remain available indefinitely.
Dormant coins make these decisions difficult. An address that has been inactive for years might belong to someone saving for the future, someone who lost their keys, or someone who has died. Inactivity alone cannot establish which explanation is correct.
Leaving vulnerable spending methods available could allow a sufficiently capable quantum attacker to take funds protected by exposed public keys. Restricting those methods could also prevent legitimate owners from spending unless they meet new recovery requirements. Draft BIP-361 proposes a migration process and restrictions on legacy signatures, but it is still a draft and has not been adopted.
Developers can propose software changes. They cannot decide on behalf of the entire network which ownership and recovery rules everyone must accept.
Further Reading: Dr. Shai Wyborski on Bitcoin’s post-quantum migration
Ethereum: Coordinating Changes Across the Network
Ethereum also needs changes beyond wallet signatures. Its post-quantum roadmap addresses user accounts, validator signatures, and cryptographic systems used to check blockchain data.
Account abstraction allows accounts to define how transactions are approved. This flexibility can support alternative signature methods, including post-quantum signatures where implemented.
How We Use Post-Quantum Cryptography at Quantus
Quantus launched with post-quantum cryptography from genesis. The design covers transaction signing, wallet keys, and connections between nodes, with a separate proof system for private transfers and scaling.
| Part of our architecture | What it does | What we use |
|---|---|---|
| Transaction signatures | What it doesLets nodes verify your authorization for transfers whose sender, recipient, and amount are publicly visible. | What we useML-DSA-65 by default, with ML-DSA-87 also supported |
| Wallet keys | What it doesGenerates post-quantum account keys and private-transfer secrets from one recovery seed. | What we useHD-Lattice key derivation |
| Node connections | What it doesLets nodes authenticate each other’s identities and establish shared secrets for encrypted communication. | What we useML-DSA-87 and ML-KEM-768 |
| Private transfers and scaling | What it doesAuthorizes private transfers and combines their proofs to reduce the data recorded per transfer. | What we useWormhole with Plonky2-based recursive proofs |
| Consensus | What it doesLets miners compete to produce blocks, while nodes select the valid chain with the most accumulated work. | What we useProof of Work using Poseidon2 |
The white paper explains the architecture and its security assumptions. Poseidon2 is a hash function chosen for efficient use inside cryptographic proofs.
Wormhole’s privacy protection concerns the link between a deposit and its destination. Amounts and exit addresses remain public, and timing or amount patterns can help observers infer connections. The Wormhole documentation explains these limits.
Where Post-Quantum Blockchain Development Stands
For holders on a chain that has not deployed a post-quantum spending option, there may be no direct migration step available yet. Progress depends on the network introducing that option and supporting its use.
Research, deployed support, and completed migration are different stages. A roadmap describes intended protection. Understanding what currently protects funds requires looking at the rules and cryptography the network actually uses. The distance between a roadmap and deployed protection is why migration begins before Q-Day.
Frequently Asked Questions
Does a Post-Quantum Blockchain Need a Quantum Computer?
Post-quantum cryptography runs on conventional computers. Developers can use it before a cryptographically relevant quantum computer exists.
Can a Blockchain Become Post-Quantum by Changing Its Signature Scheme?
A signature change covers transaction authorization. Wallets, node communication, applications, supporting services, and existing assets may still rely on older cryptography and key formats.
Does a Post-Quantum Wallet Make an Existing Blockchain Quantum-Safe?
No. A wallet cannot make the underlying blockchain quantum-safe by itself. The blockchain must accept the new cryptography, and any services involved must support the resulting transactions.
What Is the Difference Between a Post-Quantum Blockchain and a Quantum Blockchain?
A post-quantum blockchain uses cryptography designed to resist future quantum attacks and runs on conventional hardware. A quantum blockchain usually refers to experimental proposals that use quantum hardware or quantum communication within blockchain systems.
