Signature · Institutional → Quantum Core Institute
Migration-Readiness Checker
Post-quantum migration isn't one project, it's six, each on its own clock. This ranks them the way a harvest-now-decrypt-later adversary already does: by how long your data has to stay secret, not by how easy the system is to fix.
X data shelf life + Y migration time > Z time to Q-Day ⟶ already exposed
Mosca's inequality. Anything an adversary records today stays harvestable until you've migrated it, so the systems holding decade-long secrets are the emergency, even when Q-Day looks far off. That's why shelf life is the dominant weight here, not criticality.
Your systems, set shelf life, criticality, and migration status
| System | Data shelf life | Criticality | Migration status |
|---|
Criticality × migration status
Chips are colored by shelf life, the dominant weight. The hot corner, top-left, is high-criticality work that hasn't started on data that must stay secret for years. That's the harvest-now target.
Action list, shelf-life first
Ordered to match the HNDL timeline: longest-lived secrets, least migrated, at the top.
A heat-map is a starting point. A migration plan is the deliverable.
A QCI Quantum Readiness Assessment turns this into a sequenced, governance-ready migration roadmap mapped to your shelf-life exposure and the QCI-QS1 standard.
What this leaves out. A heat-map ranks shelf-life exposure against migration progress. It does not inventory specific cryptographic primitives, audit key lengths, or score governance maturity, those come from a full QCI assessment. Outputs depend entirely on the values you enter.
FAQ
What does post-quantum migration actually involve for a Bitcoin holder?
Post-quantum migration for Bitcoin is the process of moving holdings from addresses that use ECDSA (vulnerable to Shor's algorithm on a sufficiently powerful quantum computer) to addresses secured by quantum-resistant cryptography.
The technical layers of the problem:
Address exposure: Any address that has signed a transaction has broadcast its public key. These need to move first. Coins in fresh, never-signed addresses are relatively safer because only a hash is exposed — Grover's algorithm weakens hash security from 256 bits to an effective 128 bits, which remains computationally hard.
Protocol-level migration: Bitcoin's base layer still uses ECDSA and Schnorr signatures. A quantum-resistant Bitcoin would require a protocol upgrade (softfork or hardfork) to support post-quantum signature schemes (NIST-standardized options include CRYSTALS-Dilithium and FALCON). This is a network-wide coordination problem, not something individual holders can solve alone.
Custodian readiness: Institutional holders with custodied Bitcoin depend on their custodian's ability to migrate signing infrastructure. Multi-sig setups require all keyholders to coordinate. Cold storage hardware wallets may require firmware updates or device replacement.
What the checker assesses:
The readiness score across four dimensions: cryptographic inventory (what address types you hold), tooling (whether your custody setup can execute migration), timeline awareness (your estimate of quantum risk window vs. migration timeline), and coordination (whether your counterparties are aligned). A low score doesn't mean you're at immediate risk — it means the gap between your current state and a defensible state is wider than it should be.
What's the realistic timeline for individual-holder migration?
By custody type:
- Single-sig hot wallet: hours. Sweep exposed addresses to fresh ones, done
- Single-sig hardware wallet: days. Same logic, slower physical handling
- Multi-sig (2-of-3, 3-of-5): weeks. Every signer has to be available, every device has to sign, in a defined order
- Institutional custody: months. Operational change requests, board approval for moves above policy limits, audit involvement
The longer the realistic migration, the earlier it needs to start. A 6-month institutional migration window plus a 2-year protocol-readiness window means the planning horizon is now, not later.
What can a holder do today, before a PQ Bitcoin upgrade exists?
- Stop reusing addresses. Every spend should sweep to a fresh receive address
- Move coins out of legacy P2PK or pre-2017 reused P2PKH addresses today
- Document a written migration runbook — even a one-page one. The work to write it takes hours; the value is having it ready when capability arrives faster than expected
- If you custody for others, publish a quantum-readiness statement covering the four dimensions the checker scores
None of these requires a protocol change. All of them reduce blast radius if a CRQC arrives early.
How will a network-wide migration actually be coordinated?
Honestly: it hasn't been figured out. The active proposals fall into three buckets:
- Soft-fork in a PQ signature scheme alongside existing ECDSA/Schnorr, opt-in, with an extended period for holders to migrate at their own pace
- Hard deadline burn — exposed UTXOs become unspendable after a set block height, forcing migration. Controversial; not consensus today
- Commit-reveal schemes that let holders prove pre-quantum ownership using a hashed commitment, even after capability arrives
All three are live areas of BIP discussion. None has rough consensus. The checker scores readiness against the holder-side actions that work under all three paths.
Methodology
Scores custodian post-quantum readiness across four weighted dimensions and returns a 0–100 composite with a readiness band.
- Dimensions
- {key storage, signing infra, custodian roadmap, internal policy}
- Per-Dimension Score
- s_i ∈ [0, 5]
- Weight Constraint
- Σ w_i = 100
- Composite Readiness
- R = Σ w_i · (s_i ÷ 5)
Signing infrastructure and custodian roadmap carry the most weight — they determine whether you can migrate in time once the timeline tightens. A low score does not mean you are exposed today, it means you have insufficient optionality.