The Problem: Every Other Chain Needs a Hard Fork to Change Its Signature Scheme
When a cryptographic algorithm becomes unsafe, most blockchains face a hard choice. They can schedule a hard fork, coordinate every node operator to upgrade simultaneously, and hope no significant portion of the network splits off. Or they can do nothing and leave users exposed.
Bitcoin's BIP-360 proposal illustrates the best-case version of this problem. BIP-360 adds a pay-to-quantum-resistant-hash output type via soft fork, but it still requires users to actively migrate their coins to new addresses. Coins sitting in legacy addresses remain at risk. The protocol cannot move them automatically, because doing so would require spending from addresses the user controls.
QuanChain solves this differently. The Cryptographic Currency Rotation Protocol (CCRP) treats algorithm migration as a first-class protocol operation, not an emergency patch. Every transaction carries a versioned cryptographic identifier. The network can accept multiple algorithm versions simultaneously during a transition window, then retire the old one on a defined schedule, all without a fork.
What Is CCRP?
CCRP is a protocol-native mechanism that lets QuanChain migrate from one post-quantum signature scheme to another without requiring a hard fork, a soft fork, or any direct action from users. It works by embedding a two-byte algorithm version field into every transaction structure. Nodes validate against whichever algorithm that version field specifies.
This means the network can simultaneously accept transactions signed with Algorithm Version 1 and Algorithm Version 2 during a defined transition window. No transaction is rejected because it uses the "wrong" algorithm. Both are valid. Both settle to finality. The difference is that Version 1 carries an expiry countdown, and Version 2 does not.
The current production algorithm is ML-DSA-87, which produces 4,595-byte signatures and provides 256-bit quantum security. When a future algorithm is ready, CCRP activates the transition without touching the consensus rules that govern block production, fee calculation, or finality.
How Versioned Cryptographic Identifiers Work in the Transaction Structure
Every QuanChain transaction includes a crypto_version field in its header. This field is a two-byte unsigned integer. The current value for ML-DSA-87 is 0x0001. When a new algorithm is approved via governance, it receives version 0x0002, and so on sequentially.
Nodes enforce two rules about this field. First, the signature in the transaction must validate correctly against the algorithm that version number identifies. Second, the version number must appear on the network's current accepted-versions list. During a migration, both 0x0001 and 0x0002 appear on that list. After the deprecation window closes, 0x0001 is removed, and transactions using it are rejected.
This design means wallets can upgrade their signing code at any point during the parallel acceptance phase. Early adopters move to Version 2 immediately. Slower-moving wallets and exchanges follow before the deprecation deadline. No one needs to coordinate with anyone else. The protocol handles the rest.
The Three-Phase Migration Process
CCRP migrations run through three phases. Each phase has a defined block height at which it begins, set during the governance vote that approves the new algorithm.
Phase 1: Parallel Acceptance. Both the old and new algorithm versions are valid. The network accepts transactions signed with either. Wallets begin shipping updates. Validators start producing blocks that include both transaction types. This phase lasts a minimum of 90 days at current block times, giving the ecosystem time to upgrade without deadline pressure.
Phase 2: Deprecation Window. The old algorithm enters soft deprecation. Transactions using it still validate, but they pay a 2x fee multiplier. This creates a financial incentive to complete the migration without forcing anyone's hand. Validators flag deprecated-algorithm transactions in their mempool prioritization, so they settle slightly more slowly during periods of high load. This phase lasts 30 days.
Phase 3: Cutover. At the cutover block height, the old algorithm version is removed from the accepted-versions list. Any transaction using it is invalid. From this block forward, only the new algorithm is accepted. The migration is complete.
How the Quantum Threat Oracle Triggers a CCRP Rotation
CCRP migrations do not require a human to notice a threat and propose a governance vote. The Quantum Threat Oracle monitors the LQCp/h (Logical Qubit Cost per Hour) metric continuously. LQCp/h combines published qubit counts, gate error rates, and cloud quantum compute pricing into a single cost-to-attack index.
The Oracle operates on three thresholds. When it crosses T1, it triggers an on-chain alert and begins a 60-day governance window where QCH holders can vote to pre-approve a specific replacement algorithm. When it crosses T2, it activates Phase 1 of CCRP automatically, using the algorithm approved during the T1 window. If no algorithm was pre-approved, it activates the next algorithm in a pre-ranked fallback list. When it crosses T3, it accelerates the Phase 2 deprecation window from 30 days to 7 days.
This means a sufficiently rapid advance in quantum hardware cannot catch the network flat-footed. The Oracle's automated response kicks in before any human governance process could complete.
What Happens to Existing Accounts During Migration
Accounts on QuanChain store a public key commitment, not the raw public key itself. This commitment is algorithm-agnostic: it binds the account to a key without revealing which algorithm produced it. When a user generates a new key under the new algorithm, they submit a single key_rotation transaction that updates the commitment on their account. This transaction is itself signed with the old key, proving ownership before the rotation completes.
Because SpendAndRotate already rotates keys atomically with every spend, most active accounts will have migrated their key material naturally before the cutover, simply by transacting during the parallel acceptance phase. Inactive accounts (those that have not transacted during the deprecation window) face a different path: the protocol generates a migration transaction on their behalf at cutover, using a deterministic derivation from their existing commitment. The account retains the same address. The commitment updates. The user's next transaction uses their new key without any interruption.
CCRP vs Bitcoin's BIP-360: A Direct Comparison
BIP-360 introduces a new output type (P2QRH) that uses a quantum-resistant hash. Users who want protection must actively send their coins from legacy outputs to new P2QRH outputs. Legacy outputs remain spendable indefinitely: BIP-360 does not deprecate them. This means coins in addresses that reused keys (which includes the vast majority of active Bitcoin addresses) remain permanently exposed once a sufficiently powerful quantum computer exists.
CCRP differs in three ways. First, it is protocol-native: it does not require a separate output type or user migration step for existing accounts. Second, it has a hard cutover: the old algorithm stops being valid, which means the network actually completes the migration rather than leaving legacy exposure in place forever. Third, it triggers automatically via the Quantum Threat Oracle rather than requiring a governance proposal after the threat becomes apparent.
BIP-360 is a reasonable approach given Bitcoin's conservative change model. CCRP is possible on QuanChain because TADEQS was designed from the ground up to support algorithm versioning. Retrofitting CCRP-equivalent behavior onto an existing chain would require breaking changes to the transaction format.
A Worked Example: What a CCRP Migration Event Looks Like
Imagine that in early 2028, a quantum hardware announcement causes the Oracle's LQCp/h index to cross T1. The network records this crossing on-chain at block 4,200,000. A governance vote opens automatically. QCH holders vote to approve ML-DSA-65 as the replacement algorithm (a hypothetical lighter scheme with 128-bit quantum security and smaller signature sizes). The vote passes within 45 days.
At block 4,500,000 (roughly 90 days after T1), Phase 1 begins. Wallet providers push updates. Transactions start arriving signed with crypto_version = 0x0002. Validators accept both versions without configuration changes. On-chain dashboards show the ratio of Version 1 to Version 2 transactions shifting week by week.
At block 4,720,000 (30 days after Phase 1), Phase 2 begins. Version 1 transactions pay double fees. The migration rate accelerates. Exchanges complete their key rotation procedures. By day 20 of Phase 2, over 94% of transactions use Version 2.
At block 4,865,000, the cutover block, Version 1 is removed from the accepted-versions list. The remaining inactive accounts receive protocol-generated migration transactions. The network is now fully on ML-DSA-65. No fork occurred. No chain split. No user lost funds.
This is what protocol-native quantum readiness looks like in practice. For a broader picture of how CCRP fits into QuanChain's security model, see the overview of what makes a blockchain quantum-resistant and the NIST post-quantum standards that inform QuanChain's algorithm selection.
