A quantum-resistant Bitcoin migration that does not crowd out normal transactions is not a UX detail. It is the whole ballgame. I want to walk through the custody-side decision this creates — not the cryptography paper, the decision. Think of what follows as a flowchart in prose. Three questions. Each one forks. At the end there is a table that maps every answer combination to one concrete recommendation. I am writing this for people who already run cold storage, already understand what a UTXO is, and already know that "quantum-safe Bitcoin" has been a phrase in circulation since roughly 2013 without anyone doing very much about it. That is finally changing.

Question 1: Do You Hold Coins in a P2PK or Reused-Address UTXO?

This is the first fork and it is the one that determines whether you are in the "act now" bucket or the "watch and prepare" bucket. The reason it matters: any UTXO where the public key is already visible on-chain — either because the output was pay-to-public-key, or because the address was used once, spent from, and then received into again — is the class of coin a sufficiently capable quantum adversary attacks first. Not last. First. If your public key is already sitting in the block data, a Shor-capable machine does not need to wait for you to sign a transaction to derive your private key. It works from what is already visible.

Coins in fresh P2PKH, P2WPKH, or P2TR outputs where the public key has never been revealed are in a different threat class. The hash of the pubkey is visible; the pubkey itself is not. That buys time, though it does not buy immunity, because the moment you spend from that address the pubkey lands in the mempool and sits there for however many seconds or minutes it takes to confirm. That window matters in a future world where "harvest-now, decrypt-later" is not a slogan but an operational strategy.

If Yes

You have exposed UTXOs. The correct move is not to panic-spend into a quantum-resistant address that does not exist yet on Bitcoin mainnet. The correct move is to inventory. Sit down with your xpubs and your Electrum or Sparrow instance and generate the list of every address that has appeared as an input to a prior transaction. Cross-reference against your current UTXO set. Anything that overlaps — anything where you are still holding coin at an address that already spent — is the priority migration cohort.

Then you wait for the migration path to ship, but you wait actively. That means: keep watching the BIP process; keep hardware firmware current; do not consolidate exposed UTXOs into a single output today because a single consolidation transaction reveals every input's pubkey to the mempool. The consolidation is the attack window. Consolidate only when the destination is a post-quantum output type, not before.

If No

You are in the fresh-pubkey-hash cohort. Your posture is different. You do not need to touch anything today. You need to make sure that when the migration BIP ships, your signing stack can construct the new output type and your backup and recovery flow understands it. That is a firmware and software question. Which is exactly Question 2.

Free Download
Crypto Market Cycle Cheat Sheet 2026
Entry signals, exit rules & DCA calculator — based on 3 previous cycles.

Question 2: Is Your Cold Storage Signing Stack Upgradable in Firmware?

OK so here is where it gets really interesting, and I want to spend a minute on this because most people who run cold storage have never actually thought hard about what a firmware upgrade path implies for a device that is supposed to be air-gapped and permanent. The whole point of a hardware wallet is that it is boring and unchanging. You buy it, you initialize it, you write down the seed, you use it for ten years. Firmware upgrades are treated as an occasional nuisance. But post-quantum signature schemes — whether Bitcoin ends up with a Winternitz-style hash-based scheme, or SPHINCS+, or something Falcon-adjacent, or the specific construction the recent researcher proposal describes — will require the signing device to implement new curves, new hash routines, new key derivation, and often significantly larger signature payloads. That is not a "download the update" event. That is potentially an "is your device even physically capable of running the new firmware" event.

I love this detail, so let me explain what it splits into. There is a class of hardware wallet where the secure element is a general-purpose microcontroller with plenty of flash and RAM headroom, and firmware upgrades can plausibly ship new signature schemes without hardware replacement. And there is a class where the constraint is tighter — the SE is optimized for ECDSA and Schnorr specifically, and adding a hash-based scheme with signatures that could be an order of magnitude larger than a current 71-byte DER-encoded ECDSA signature is a real engineering problem.

The three devices worth watching here, per the local operator list I am allowed to reference on this desk: Ledger, Trezor, and the GridPlus Lattice1. The Lattice1 is interesting because of its co-signer abstraction — signing operations are not exclusively bound to the device's own key material, which matters if the migration path involves a hybrid signing scheme during transition. Ledger and Trezor both have established firmware update pipelines, but the question you actually need answered — and this is the one nobody in the marketing pages will answer for you — is whether the current generation of secure element can hold the working memory required for a post-quantum sign operation. That is a specification question. Ask your vendor.

If Yes

Your device can plausibly receive a post-quantum firmware update. Good. Now the follow-up: are you actually running an official firmware release from the vendor, or are you running a fork, a stripped build, or a two-year-old version that never gets updated because you keep the device offline in a vault? Update discipline is the thing that turns "capable of upgrade" into "will actually be upgraded when it counts". Set a recurring reminder to check firmware quarterly. It is a boring reminder. Set it anyway.

If No

You need a hardware replacement path. This is not a today emergency because there is nothing to migrate to yet, but it is a next-eighteen-months planning item. Budget for it. Identify the vendor you will replace with. And critically: rehearse the seed-to-new-device recovery on a test setup before you ever need to do it under pressure with real value at stake. The number of self-custody stories I have watched go sideways because someone did their first-ever recovery drill on the day the quantum warning fires is not zero. Do not make it your story.

Question 3: Are You Custodying for Others or Only for Yourself?

This is the fork that separates a personal migration question from a fiduciary one, and the two answers look almost nothing alike. If you are securing your own Bitcoin, you can afford some latitude — you can wait for the BIP to ship, watch two or three exchanges implement it first, learn from their post-mortems, and migrate on your own schedule. Your worst case is that you personally get liquidated by a quantum adversary, which is bad, but it is bounded by your own balance and your own risk tolerance.

If you are running a qualified custodian, a family office, a fund, or an OTC desk with hot and warm wallets holding other people's coins, the calculation flips entirely. You have compliance obligations, insurance policies with specific exclusions, and disclosure requirements that force you to make decisions on a timeline that is not your own. Your worst case is not "I lose my coin". Your worst case is "I am the first custodian to lose someone else's coin to a quantum attack in a way that was foreseeable and I did nothing" — which is a career-ending, firm-ending event before it is anything else.

If Yes

You are in the fiduciary bucket. The operators to model your own posture against, from the list this desk covers: Coinbase Custody (NY DFS Trust Company), Fidelity Digital Assets (NY DFS Trust), and Anchorage Digital (OCC Federal Trust Charter — first crypto bank). What you want to know about each of them is not what they say publicly about quantum readiness. It is what their custody agreements say about signature scheme migrations, whether the agreement obligates them to migrate coins to new output types when a BIP-defined post-quantum type becomes available, and who bears the cost of doing so. Read the actual documents. If your custodian is not one of these three and you cannot find those clauses, that is the story.

Internally, your fiduciary posture requires you to document a migration plan today, even though the migration itself cannot happen today. Regulators do not accept "we were waiting for the ecosystem" as an answer when the ecosystem has been talking about this for a decade. The proposal that finally doesn't crowd out normal transactions is the trigger that flips this from academic to actionable.

If No

You are in the personal-custody bucket. Your job is quieter. Watch the BIP process, keep your signing stack current, and when the migration path exists on mainnet, execute it on a schedule that suits you. There is no compliance officer standing over your shoulder. There is only the discipline of doing it before you need to do it under duress. A migration executed calmly, with the destination address verified and the change output correctly scripted, is a boring afternoon. A migration executed the day the first quantum-attack tweet goes viral is a way to lose coins to a fat-finger error or a rushed change-address mistake, both of which happen more often than the underlying cryptographic failure they are trying to escape.

The Math Teardown: What "Doesn't Crowd Out Transactions" Actually Buys You

Let me put numbers on this because the whole reason the proposal matters is a specific mempool arithmetic problem, and the arithmetic is worth working through even though the exact per-signature byte figures for the specific scheme sit outside the grounding I can cite here.

Start from what is grounded. Bitcoin's max supply is 21,000,000 BTC. Circulating supply is roughly 19,800,000 BTC. That is 94.29% of coins issued (19.8M ÷ 21M). At the current price of $64,349, that circulating supply is worth $1,290.97 billion — the market cap figure the desk uses. At the January 2025 ATH of $109,000, the same 19.8M coins would be worth $2,158.2 billion. The gap between ATH price and current price is a 40.96% drawdown from peak (1 – 64,349 ÷ 109,000). Every one of those coins lives in a UTXO. Every UTXO has a script. Every script will need to either be migrated or accepted as legacy-and-therefore-unspendable-post-quantum in the world where a Shor-capable machine is real.

A naive migration — everybody spend from your old outputs into new post-quantum outputs in a compressed window — is what "crowds out transactions" means. If a hundred million UTXOs all try to move in the same six-month period, average blockspace demand jumps by whatever the ratio is between migration transactions and organic transactions in that window. Fees spike. Small-value UTXOs become uneconomic to migrate because the fee to move them exceeds their value. Coins get stranded. The proposal that does not crowd out transactions is the proposal that lets migration happen without breaking that arithmetic — either by amortizing the migration over a longer window, or by making the migration transactions smaller than a naive scheme would produce, or by allowing batched migration where many UTXOs move under one signature. Which specific mechanism the current researcher proposal uses is a paper I cannot cite from within this grounding envelope — the point I can make is that the reason to care is the mempool math, not the cryptography.

If You Answered Everything: The Decision Matrix

Here is the map from every answer combination to one concrete recommendation. Read your row, execute the sentence.

Q1: Exposed pubkeys?Q2: Firmware upgradable?Q3: Custody for others?Recommendation
YesYesYesInventory exposed UTXOs now, document migration plan for regulators, hold consolidation until PQ output type is live.
YesYesNoInventory exposed UTXOs, keep firmware current, migrate on personal schedule once BIP ships and two exchanges have executed cleanly.
YesNoYesFiduciary emergency: budget hardware replacement this quarter, disclose the migration risk to counterparties, run recovery drills.
YesNoNoPlan hardware replacement in next 18 months, rehearse recovery drill on test setup, do not consolidate exposed UTXOs today.
NoYesYesWatch BIP process, document custody agreement obligations for PQ migration, do not touch coins yet.
NoYesNoSet quarterly firmware-update reminder, otherwise no action needed until migration BIP ships.
NoNoYesFiduciary planning: replace hardware in next 12 months, verify custody agreement covers PQ scheme migration cost allocation.
NoNoNoReplace hardware within 18 months, otherwise nothing to do — you are in the lowest-urgency bucket.

The matrix collapses to a simple observation: exposed pubkeys plus fiduciary responsibility plus non-upgradable hardware is the row that requires action this quarter. Everything else is either "watch" or "plan". That is the whole decision. The rest is discipline.

The Condition That Would Reverse This

I would reverse the entire posture above — specifically the "wait for the BIP, do not panic-migrate today" default — if a credible cryptographic breakthrough demonstrated a working Shor implementation against elliptic-curve keys of Bitcoin's size on hardware that a well-funded adversary could plausibly assemble within twelve months. That is the condition. Not a paper suggesting theoretical progress. Not a NIST update to their standardization timeline. A working demonstration against ECDSA-secp256k1-class keys. Until that condition is met, the arithmetic favors patience, and the operational risk of a rushed migration exceeds the cryptographic risk of holding position. If it changes, this article changes. Until it changes, the matrix above holds.

FAQ

How urgent is post-quantum Bitcoin migration if I only self-custody my own coins?

Not urgent today for most self-custody users, but not something to ignore either. If your UTXOs are all in fresh addresses where the public key has never been revealed on-chain, you have meaningful time. If you hold coins in P2PK outputs or in addresses that have already been spent from and reused, you are in the priority cohort and should inventory those UTXOs now so you can migrate cleanly the moment a mainnet PQ output type exists.

Do current hardware wallets like Ledger, Trezor, or GridPlus Lattice1 support post-quantum signatures?

No — no shipping hardware wallet today implements a Bitcoin post-quantum signature scheme because no such scheme is deployed on Bitcoin mainnet yet. The relevant question is whether your device's hardware could receive a firmware update implementing one when a BIP ships. Ledger, Trezor, and the GridPlus Lattice1 all have active firmware pipelines, but per-device capability depends on secure element headroom and vendor commitment. Ask your vendor directly.

Why does a quantum migration risk crowding out normal Bitcoin transactions?

Because a naive migration path would require every holder with vulnerable UTXOs to spend from the old output type into a new post-quantum output type inside some finite window. If that window is short, aggregate blockspace demand jumps sharply and fees spike, which prices out small-value UTXOs and can strand coins. Proposals that "do not crowd out transactions" typically address this by amortizing migration across a longer window or reducing the per-migration byte footprint.

Are qualified custodians like Coinbase Custody or Fidelity Digital Assets ahead of self-custody on this?

They face different obligations, not necessarily better preparation. Coinbase Custody operates under a NY DFS Trust Company charter, Fidelity Digital Assets under NY DFS Trust, and Anchorage Digital under an OCC Federal Trust Charter. All three have documented custody agreements that will need to address who bears the cost of a signature-scheme migration and on what timeline. Read the actual agreement rather than assuming the license implies readiness.

What is a P2PK output and why does it matter for quantum risk?

A pay-to-public-key output puts the full public key directly in the locking script on-chain, rather than only its hash. Some of the earliest Bitcoin outputs — including many attributed to the first years of mining — are P2PK. Because the public key is already visible, these outputs are attackable by a Shor-capable adversary without waiting for the owner to sign a spending transaction. They sit at the top of the priority list in any post-quantum threat model.

Should I consolidate my Bitcoin UTXOs now to prepare for migration?

No — not into a legacy output type. A consolidation transaction reveals the public key of every input to the mempool during the confirmation window, which is precisely the exposure you want to avoid. Consolidate only when the destination is a post-quantum output type that has shipped as a BIP-defined script format on mainnet. Consolidating today into a P2WPKH or P2TR output moves your risk profile in the wrong direction.

How does the current Bitcoin market context inform the migration urgency?

Circulating supply is roughly 19.8 million BTC, or 94.29% of the 21 million maximum. At the current price of $64,349, that is $1,290.97 billion of value living in UTXOs whose scripts will eventually need a migration decision. The scale is what makes "does the migration crowd out normal transactions" the operationally decisive question rather than an academic one — the aggregate size of coins to be migrated is the constraint the proposal is trying to solve for.