About this tool
Migrating a blockchain deployment to post-quantum cryptographic standards is not a single action. It is a multi-component programme that spans protocol-level signature scheme changes, governance processes, node software updates, smart contract migration or redeployment, key management infrastructure changes, hardware wallet and HSM updates, and cross-chain interoperability assessment. The effort required varies by orders of magnitude depending on the deployment type. A private single-operator chain can plan and execute migration unilaterally within months. A global public chain with anonymous validators, a contentious governance history, and billions of dollars in smart contract value requires community consensus, multi-year coordination, and no comparable precedent to draw on.
The algorithms that will replace ECDSA in post-quantum blockchain deployments are now standardised. NIST FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) and NIST FIPS 205 (SLH-DSA, formerly SPHINCS+) are finalised. Falcon (NTRU-based) remains a candidate for signature schemes requiring smaller signature sizes and is under active consideration for blockchain contexts. The constraint on migration is not algorithm availability; it is deployment feasibility.
One practical consideration that frequently surprises blockchain operators is signature size. A single ECDSA secp256k1 signature in DER format is approximately 71 bytes. An ML-DSA-87 signature (the highest security parameter set under NIST FIPS 204) is 3,309 bytes per signature. Per transaction input, this represents a 46x increase in signature size. Falcon-512 (666-byte signatures, 897-byte public keys) significantly reduces both figures.
This tool estimates migration effort across three output dimensions: effort band (Low, Moderate, High, Very High, Extreme), indicative programme duration, and indicative cost range. These are directional estimates based on your answers. They are not a project plan, a procurement specification, or an engineering assessment.
Scoring dimensions: Chain type (20%), network size (15%), smart contract surface (15%), key management (15%), on-chain data volume (10%), cross-chain dependencies (10%), regulatory obligations (5%), governance complexity (5%), and team quantum readiness (5%). Cost ranges are illustrative order-of-magnitude benchmarks. Actual costs depend on engineering team rates, geography, HSM vendor pricing, consultant fees, governance process costs, and smart contract audit costs. Extreme-band public chain migrations have no comparable precedent; cost and duration figures do not apply.
Important Information About How We Use This Data
Quantum Security and Defence does not collect, associate, or retain your name or your company name when you use these tools. All information is stored only for the duration of the browser session.
We collect only country, industry, and results data. This information is anonymised and cannot be associated with you or your company. Such anonymised data may be used for industry-level reporting, shared with members, incorporated into our research, and provided to government departments to support lobbying activity and the communication of industry readiness.
By using this tool, you consent to the provision of results data on a strictly anonymised basis. No personal name, email address, or company name is stored.
Which country is this blockchain deployment based in?
Country is recorded anonymously for industry-level reporting and to tailor regulatory context to your jurisdiction.
Country is recorded anonymously for industry-level reporting only. No email, name, or company details are transmitted or stored.
Which sector best describes your blockchain deployment?
Select the sector that best describes the primary use case of this blockchain deployment. Sector context helps tailor the cost benchmarks and regulatory considerations in your results.
The Industry selection is required and recorded anonymously. Your industry may impact your score. Be sure to choose your nearest industry category.
About You
Not recorded. Only used to create your PDF report in the browser session.
Not recorded. Only used to create your PDF report in the browser session.
Optional. No email, name, or company details are transmitted or stored. Your name and company will appear on your PDF report only.
What type of blockchain deployment is this, and which signature scheme is in use?
The chain type determines the fundamental scope of the migration. For public permissionless chains, migration requires ecosystem-wide consensus. ECDSA and ed25519 are quantum-vulnerable; ML-DSA (NIST FIPS 204) and SLH-DSA (NIST FIPS 205) are the post-quantum replacements. Falcon (NTRU-based) is under active consideration for blockchain contexts due to its smaller signature size.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
How many participants, validators, or nodes does your network have?
Every node that does not upgrade to post-quantum software either fragments the network (in hard fork scenarios) or blocks the migration (in chains requiring supermajority adoption). For public chains, upgrading the validator set is a function of community adoption. For permissioned chains, it requires coordinated software rollout across all contracted participants.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
How extensive is the smart contract and application surface that would need to be updated or redeployed?
Smart contracts that verify signatures internally may need to be redeployed rather than simply upgraded. Contract redeployment involves new contract addresses, migration of existing state, updating all integrations and front-end references, and coordinating with users. A chain with no smart contracts has a materially lower contract migration burden.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
How are signing keys managed in your deployment?
Post-quantum migration requires generating new key pairs under post-quantum algorithms. Where key management is handled by hardware (HSMs, hardware wallets), migration depends on firmware or hardware updates from the device vendor. BIP32/BIP39 hierarchical deterministic wallets are not structurally compatible with the key derivation requirements of current post-quantum schemes.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
How many cross-chain bridges, oracles, or external integrations does your deployment depend on?
Cross-chain bridges verify signatures from other chains. If your chain migrates to post-quantum signatures but connected chains do not, bridges need to support both signature formats simultaneously or bridge functionality will break. The breadth of this integration surface is a significant multiplier on migration complexity.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
Does your deployment face formal regulatory deadlines for post-quantum cryptography migration?
The NSA CNSA 2.0 framework sets 2030 as the target transition date for key establishment in national security systems and 2033 for digital signatures. Where a formal regulatory deadline is shorter than your realistic migration programme, that gap is a risk that requires escalation. This field affects the urgency framing of your results.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
What governance structure does your deployment operate under?
Migration decisions require authorisation. The authorisation process adds time to any programme, independent of technical complexity. A single organisation with clear executive sponsorship can approve a migration programme quickly. A consortium with a formal voting process may require six months of governance engagement before a technical programme can begin.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
Does your technical team have experience with post-quantum cryptographic algorithms?
PQC engineering is a specialist discipline. Implementing ML-DSA (NIST FIPS 204), integrating it into a blockchain node, handling signature format changes, and testing for correctness requires cryptographic engineering skills that most blockchain development teams do not yet have in-house.
Your answer is used only to calculate your effort estimate. Nothing is transmitted from your browser.
QSECDEF Intelligence
Quantum security developments, weekly
NIST standards updates, blockchain PQC research, migration programme case studies, and sector briefings. For security teams managing quantum transition programmes.