There is a pattern I keep seeing every time a Tier-1 asset manager publishes a quantum-risk note on Bitcoin. VanEck's is the most recent. The bitcoin community — the Twitter half, the Nostr half, the custody-desk half — nods, concedes the point in principle, and then does nothing operationally for the next six months. Meanwhile the number that should be deciding the conversation is sitting in plain sight: Bitcoin's market cap is $1,290.97 billion against a circulating supply of 19.8 million coins on a protocol that launched in 2009 on Proof-of-Work. Sixteen years of address-level history exposed to a threat model the original design never budgeted for. That is the receipt.
The Community-Acknowledgment Loop That Substitutes For Action
The pattern is not that the community denies quantum risk. It is that the community concedes it so gracefully that the concession itself becomes the mitigation.
Every VanEck-style note gets the same three-part reception. A dignified retweet from the maximalist wing. A "this is why we need Taproot-only outputs everywhere" thread from the technical wing. And a "the timeline is still 15+ years" reply from the sober wing that ends the conversation. Nobody moves coins. Nobody rotates addresses. Nobody rewrites custody policy. The acknowledgment closes the loop, and the loop is the point.
I keep watching this because the loop has a signature. It reads like a governance response and functions like a stall. The Bitcoin protocol launched in 2009 — that number matters because ECDSA over secp256k1 was a defensible choice in 2009 and is a deferred liability in 2026, and every year that passes without a signed migration schedule is another year of exposed public keys accumulating on chain. The community reads a note like VanEck's, agrees the threat is real in principle, and moves on. The reason moving on is the default is that the alternative — actually migrating hundreds of billions of dollars of custody across a soft-fork transition — is the hardest operational problem in the asset class, and nobody wants to volunteer to be the first custodian to break something.
So the acknowledgment substitutes for the migration. And the substitution is stable, which is why I keep seeing it.
The Address Reuse Debt Sitting on 16 Years of On-Chain History
There is a specific technical shape to why quantum risk on Bitcoin is not a protocol problem first — it is a custody problem first. And the shape is address reuse.
An untouched P2PKH or P2WPKH address exposes only a hash of the public key. The actual public key is not revealed until the address spends for the first time. Post-quantum, that means: unspent addresses that have never broadcast are meaningfully safer than addresses that have. Once you spend from a reused address, the public key is on chain forever, and every subsequent balance sitting at that address is exposed for the entire lifetime of a sufficiently capable adversary. This is not speculation about cryptographic timelines. It is a property of the ledger that has been visible in every block since 2009.
Now overlay the age of the chain. Bitcoin launched in 2009. That is 16 years of block history where address reuse was the norm before it was mildly discouraged, then the norm before HD wallets made rotation cheap, then still the norm at exchanges and custodians whose accounting systems assumed static deposit addresses. Coinbase Custody, Fidelity Digital Assets, Anchorage Digital — these are qualified trusts that publish reserve attestations, but the attestations do not itemize the address-reuse posture of the underlying wallets. The reader is expected to trust that "cold storage" means "post-quantum-hardened cold storage." I have not seen a trust attestation that discloses whether the cold vault addresses have ever broadcast.
The number I keep coming back to is 19.8 million. That is the circulating supply. A material fraction of that supply is sitting at addresses whose public keys are already on chain. Nobody has published a defensible estimate of the fraction — which is itself a data availability failure — but the direction is not in dispute. The custody layer is where the address-reuse debt is concentrated, because the custody layer is where accounting convenience overrode cryptographic hygiene for a decade.
The Custody Assumption Nobody at the Qualified Trust Level Audits
Here is what the qualified custodian tier — Coinbase Custody as a NY DFS Trust, Fidelity Digital Assets as a NY DFS Trust, Anchorage Digital as an OCC Federal Trust Charter — actually gets audited on. SOC 2 controls. Segregation of client assets. Reserve attestations against liabilities. Key ceremony process. Physical security of HSM installations. All of that is real, and I do not want to minimize it.
Here is what they do not get audited on. The cryptographic migration roadmap of the addresses that hold the bulk of client assets. Whether the vault architecture assumes ECDSA is durable through the trust's operational horizon. Whether the client agreement contemplates a soft-fork migration event that requires moving coins to post-quantum output types before a threshold date. Whether the HSMs in the key ceremony are capable of signing post-quantum schemes at all, or whether the entire hardware fleet is a forklift-replacement problem when the schedule arrives.
The qualified custodian audit surface stops at operational security. The quantum threat lives one layer deeper, and that layer is not in the attestation.
This is the gap that VanEck's note points at without naming. When a Tier-1 asset manager writes that quantum is a real risk on Bitcoin's roadmap, the operational translation is: the custody providers holding institutional Bitcoin allocations need a documented migration policy, and the policy needs to be part of the trust agreement, and the trust agreement needs to specify who bears the cost of a mandatory address rotation. None of that is standard today. The standard today is "cold storage" as a marketing term and a SOC 2 report as the audit floor.
I am not saying Coinbase Custody or Fidelity or Anchorage are doing this badly. I am saying the audit regime they operate under does not require them to disclose the answer. And when a regulated custodian is not required to disclose the answer, the market cannot price the difference between a custodian that has quietly migrated their vault architecture and a custodian that has not. That opacity is the second-order risk sitting under VanEck's note.
The Hardware Wallet Firmware Gap Between Acknowledgment and Migration Path
Self-custody has the opposite problem. The audit surface is much thinner — a hardware wallet is a device you can hold — but the migration path is entirely on the user.
Ledger, Trezor, and GridPlus Lattice1 are the three vendors whose firmware histories I actually track. Ledger ships from Paris, Trezor from SatoshiLabs in the Czech Republic, GridPlus Lattice1 with its co-signer abstraction from the US. All three sign transactions using secp256k1 today. All three have engineering teams that read the same quantum literature the rest of us read. None of them ships a production post-quantum signing path in 2026, which is the correct engineering decision — there is no finalized post-quantum signature scheme for Bitcoin at the consensus layer, so there is nothing to sign against. But it means every hardware wallet in the field today is a device whose migration story is "we will ship a firmware update when the protocol tells us what to sign," and the protocol has not told them.
That leaves the user with a specific operational problem that nobody in the mainstream Bitcoin conversation frames sharply enough. If you hold Bitcoin on a Ledger, Trezor, or Lattice1, and the protocol adds a post-quantum output type in a future soft fork, you will need to do three things in sequence: receive the firmware update, verify the update out-of-band against the vendor's release signing key, and then broadcast a transaction that moves your coins from a legacy output to a post-quantum output. That broadcast reveals the public key of the legacy address. Which means the migration transaction itself is the moment of maximum exposure, and the coins are only safe after the migration is confirmed.
The math teardown on this looks like the following. Take a self-custody holder with 1 BTC at the current price of $64,349 per coin. That is $64,349 of exposure. If the migration window is announced with a 6-month grace period, and the holder is on the last day of that window, the mempool congestion during a coordinated cross-community migration is going to be dramatic. Bitcoin's block space is fixed at roughly 4 million weight units per 10-minute block. A P2WPKH-to-post-quantum migration transaction is going to weigh more than a standard P2WPKH-to-P2WPKH transfer because the output type is larger. If half of the 19.8 million circulating supply needs to migrate in that window, and each transaction averages 200 vbytes at a post-quantum output size premium of roughly 40% over current SegWit weights, the total block space demand is 19,800,000 coins divided by an average UTXO cluster size of maybe 3 to 5 coins per UTXO (I am estimating the cluster size — the exact distribution is not in my grounding), producing 4-7 million transactions worth of migration demand. At Bitcoin's roughly 2,000-3,000 transactions per block throughput, that is a queue of 1,300 to 3,500 blocks — 9 to 24 days of pure migration traffic if it all lands in the last week of the window. Fees would be pathological. That is the operational number the community-acknowledgment loop is not paying attention to.
The hardware wallet vendors know this. The migration is not a firmware problem alone. It is a firmware problem plus a mempool congestion problem plus a fee-market problem plus a user-experience problem where the average holder has never signed a soft-fork migration transaction in their life. The gap between "we acknowledge quantum risk" and "here is the documented migration procedure with fee estimates and grace period math" is where every self-custody operator is currently sitting. And the acknowledgment is doing the work of the procedure, which is the recurring pattern.
So What Do You Actually Do
If you are holding Bitcoin at a qualified custodian, ask them one specific question in writing. Does the trust agreement contemplate a mandatory address rotation event, and who bears the cost. Not "are you thinking about quantum risk" — every custodian will say yes and change nothing. The written question about the trust agreement is the one that produces either a real answer or a real silence, and the silence is itself a data point you can act on.
If you are holding Bitcoin in self-custody on a Ledger, Trezor, or Lattice1, do two things this quarter. First, audit your address reuse posture — check whether the addresses currently holding your balance have broadcast before, because a first-spend from a reused address is where the public-key exposure is created. If they have, plan a consolidation into fresh outputs at a low-fee window, not urgently, but before the community-wide migration pressure arrives. Second, subscribe to your hardware wallet vendor's release-signing key channel directly, not just their marketing announcements. When the migration firmware ships, the signing-key verification path is the only thing between you and a fake update in the maximum-panic window.
If you are holding an institutional allocation and reading this because a compliance team asked you to have a view, the operational answer is that the migration cost — not the cryptographic risk — is what needs to be in the risk memo. VanEck's note surfaced the acknowledgment. The next writeup is the one that costs out the migration and puts it on a schedule.
$1,290.97 billion of market cap sitting on a signature scheme with a documented shelf life. That is the number that should be deciding whether "we acknowledge the risk" counts as a risk-management posture at your custodian. It does not.
FAQ
Is VanEck saying Bitcoin is broken by quantum computing today?
No. VanEck's note is a roadmap-level acknowledgment that the ECDSA signature scheme Bitcoin has used since 2009 is not post-quantum safe, and that the community needs a migration plan. The immediate risk is not that quantum computers exist today at the required capability. The immediate risk is that the migration path has not been designed, and designing it under time pressure produces worse outcomes than designing it deliberately over the next several years.
Does Proof-of-Work protect Bitcoin from quantum attacks?
Only partially, and only for the mining layer. Proof-of-Work protects the ordering of transactions and the difficulty of rewriting history. It does not protect the ownership layer, which relies on ECDSA signatures over secp256k1. A quantum adversary capable of breaking ECDSA does not need to attack the mining layer at all — they can simply spend coins from addresses whose public keys are on chain. This is why the custody layer, not the consensus layer, is the first surface at risk.
Which custodians publish a documented quantum migration policy?
As of 2026, none of the three qualified custodians most cited in institutional allocations — Coinbase Custody as a NY DFS Trust, Fidelity Digital Assets as a NY DFS Trust, Anchorage Digital as an OCC Federal Trust Charter — publish a client-facing quantum migration policy that specifies triggers, timelines, and cost allocation. Their audit regimes cover operational security under SOC 2 and reserve attestations, but do not require quantum-migration disclosure. Ask in writing if you are an institutional client.
If I move my coins to a fresh address, am I safe from quantum risk?
Safer, not safe. A fresh P2WPKH or Taproot address that has never broadcast exposes only a hash of the public key, not the key itself. That is the defensible posture until the protocol adopts a post-quantum output type. Once you spend from that address, the public key is on chain and the address becomes exposed for the remaining lifetime of the coins at that address. Address hygiene is a delay, not a solution.
What is the practical difference between Ledger, Trezor, and Lattice1 on quantum readiness?
As of 2026, all three sign using secp256k1 and none ship a production post-quantum signing path, because Bitcoin has not standardized a post-quantum output type at the protocol level. The differentiator is the vendor's firmware release-signing infrastructure and their historical response time to protocol upgrades. Ledger from Paris, Trezor from SatoshiLabs in the Czech Republic, and GridPlus Lattice1 with its co-signer abstraction all have distinct threat models — evaluate them on release-key custody, not on quantum marketing claims.
Should retail holders panic-migrate their Bitcoin now?
No, because there is nothing to migrate to at the protocol level yet. The correct posture for a retail self-custody holder is to consolidate any reused addresses into fresh outputs at a low-fee window this year, subscribe directly to your hardware wallet vendor's release-signing key channel, and be ready to execute a migration transaction within the first weeks of a soft-fork migration window rather than waiting for the deadline. The panic-window migration is where the mempool congestion and fee pathology will concentrate.
How much of the circulating 19.8 million BTC supply is at exposed addresses?
The direction is well understood but no defensible aggregate estimate is published in a form I would cite as a hard number. The exposure comes from every UTXO whose parent address has broadcast at least once, plus every early-era P2PK output whose public key was published directly on chain from block one. Both categories are non-trivial fractions of the 19.8 million supply. The absence of a published aggregate is itself the disclosure gap that quantum-readiness reporting will eventually have to close.