Crypto custody & compliance · engineering reference
Signatures break before hashes do. The useful work now is an exposure inventory, address hygiene, exportable metadata, and crypto-agile interfaces—not a confident prediction of “Q-day.”
Quantum risk in custody is a signature problem, not an encryption problem. A sufficiently large quantum computer would recover a private key from a published elliptic-curve public key, and that is what nearly every chain uses to authorize spending. Hash functions are far less affected.
No existing machine is close, and the honest answer about timing is that nobody has a date. What is knowable today is exposure: which of your outputs have already published an elliptic-curve public key, because those are the ones a future machine would target.
An unspent output that shows only a hash of the key is not yet a target. Spending reveals the public key, and that transition only runs one way. Not reusing addresses is the one control fully available right now.
Because a chain has to validate them first. The standardised schemes are also one to two orders of magnitude larger than the 64 to 72 bytes chains budget for today, which changes fees, block space, and every place a signature is stored.
Build the exposure inventory, fix reuse policy, confirm keys and derivation paths can be exported without the vendor, and keep the signature scheme behind an interface. That work pays off whatever the timeline turns out to be.
If you remember one lineInventory and hygiene are available today. A confident Q-day prediction is not.
The useful work now is an exposure inventory and address hygiene. Everything else waits on chain rules that do not exist yet.
Exposure is a property of published keys and spend history. Capability timing is uncertain; inventory and hygiene are not.
| Question | If yes | Verdict |
|---|---|---|
| Is an elliptic-curve public key already visible? | Long-range key-recovery target under a future CRQC | INVENTORY NOW |
| Is only a hash of the key/script visible and unused? | Long exposure is reduced until spend reveals it | NO REUSE |
| Does the chain validate a standardized PQ signature today? | Only then can a true scheme migration execute | CHAIN DEPENDENT |
| Does the custody quorum have a mature audited PQ threshold protocol? | Only then can threshold semantics survive directly | EMERGING |
| Can keys, paths and policy be exported/re-keyed without the vendor? | Migration remains operationally possible | TEST EXIT |
The question is not when a quantum computer arrives. It is which of your outputs have already published an elliptic-curve public key.
Post-quantum signatures are one to two orders of magnitude larger than the 64–72 bytes chains budget for today. Bars are relative to the largest standardised signature.
| Scheme | Public key (bytes) | Signature size relative to the largest | Signature (bytes) | Standard |
|---|---|---|---|---|
| ML-DSA-65 | 1,952 | 3,309 | FIPS 204 | |
| ML-DSA-87 | 2,592 | 4,627 | FIPS 204 | |
| SLH-DSA-SHA2-128s | 32 | 7,856 | FIPS 205 | |
| SLH-DSA-SHA2-128f | 32 | 17,088 | FIPS 205 |
Exposure is not present-day compromise. It identifies which assets would offer a future cryptographically relevant quantum computer an unbounded attack window.
| Holding/output type | What is published at rest | Exposure moment | Long-range verdict | Action now |
|---|---|---|---|---|
| Bitcoin P2PK | Raw public key | Creation | EXPOSED | Inventory and plan migration |
| Bitcoin P2PKH, never spent/reused | Hash of public key | Spend reveals key | HASH-SHIELDED | Do not reuse address |
| Bitcoin P2PKH after spend + reused balance | Public key in prior input | First spend | EXPOSED | Sweep to fresh non-reused output |
| Bitcoin P2WPKH, never spent/reused | Witness program hash | Spend reveals key | HASH-SHIELDED | Do not reuse address |
| Bitcoin P2SH/P2WSH unspent | Script hash | Spend reveals script/keys | DEPENDS | Inspect revealed history and reuse |
| Bitcoin P2TR | Tweaked Schnorr public key | Creation | EXPOSED AT REST | Include in exposed inventory |
| Proposed P2MR / BIP 360 | Merkle root, no key path | Script-path spend | DRAFT | Track; not deployable consensus today |
| EVM account never sent | Address hash; key not directly published | First signature enables recovery | UNTIL SEND | Avoid reuse after outbound activity |
| EVM account that sent | Recoverable signer key from signature | First outbound transaction | EXPOSED | Inventory and migration dependency |
| Ed25519 account after signing | Public key/signature visible by chain design | Account/signature use | EXPOSED | Chain-specific inventory |
| xpub / wallet descriptor leak | Public derivation material | Export/disclosure | MANY KEYS EXPOSED | Treat as sensitive; rotate where feasible |
“Quantum breaks Bitcoin mining” is the wrong operational model. The actionable custody inventory is signature schemes and public-key exposure.
| Primitive | Role | Quantum effect | Operational consequence |
|---|---|---|---|
| ECDSA / secp256k1 | Bitcoin/EVM signatures | Shor breaks discrete-log assumption | Exposed public keys become key-recovery targets |
| Schnorr / secp256k1 | Taproot signatures | Same curve assumption | Output key is exposed at rest |
| Ed25519 / EdDSA | Account/chain signatures | Elliptic-curve discrete log | Used accounts require chain migration |
| SHA-256 | Hash commitments / PoW | Grover gives quadratic generic search speedup | 256-bit hash retains large margin; signatures are priority |
| RIPEMD-160 / HASH160 | Bitcoin key hash | Generic search speedup | Unspent hash-shielded outputs differ from raw-key outputs |
| Merkle commitments | Transaction/script/state commitments | Hash security reduction, not Shor break | Not the primary signing failure |
Parameters were checked against FIPS 204/205. On-chain cost depends on future serialization and consensus weight rules; multiplying raw bytes by today's witness fee formula would be illustrative, not a deployable quote.
| Scheme / parameter | Public key bytes | Signature bytes | Class | Custody reading |
|---|---|---|---|---|
| ECDSA secp256k1 baseline | 33 compressed | ~71–73 DER | Classical | Compact; quantum-vulnerable |
| Schnorr BIP340 baseline | 32 | 64 | Classical | Compact; quantum-vulnerable |
| ML-DSA-44 | 1,312 | 2,420 | NIST FIPS 204 | ~38× a 64-byte Schnorr signature |
| ML-DSA-65 | 1,952 | 3,309 | NIST FIPS 204 | Higher category; larger witness |
| ML-DSA-87 | 2,592 | 4,627 | NIST FIPS 204 | Largest ML-DSA standard set |
| SLH-DSA-SHA2-128s | 32 | 7,856 | NIST FIPS 205 | Small key; very large signature |
| SLH-DSA-SHA2-128f | 32 | 17,088 | NIST FIPS 205 | Faster family variant; larger signature |
An already published public key can be attacked for months or years without broadcasting anything.
Concrete use: P2PK, P2TR, reused key-hash outputs, used accounts, and leaked xpubs enter the exposed inventory now.
Failure mode: Waiting for a mempool anomaly misses the quiet attack window.
An attacker derives a key after spend broadcast and races a conflicting transaction before confirmation.
Concrete use: Hash-shielded P2WPKH still needs a chain-level PQ signature path to close this window.
Failure mode: Moving to a fresh key-hash output only addresses long exposure.
Reduce exposed reuse without claiming quantum safety.
Concrete use: Stop address reuse, protect xpubs/descriptors, and sweep long-held reused balances through ordinary controlled ceremonies.
Failure mode: A rushed migration can cause a certain operational loss to hedge an uncertain future threat.
As of August 2026, NIST's MPTC program is actively collecting threshold schemes under IR 8214C. That is progress, not proof of mature interoperable custody deployments.
| Path | Address continuity | Threshold quality | Chain dependency | Primary failure |
|---|---|---|---|---|
| Classical threshold + separate PQ signature | Contract/script dependent | Hybrid, asymmetric | Needs verification rule | PQ key may reintroduce single point |
| Upgradeable smart-contract/account wallet | Can remain stable by contract design | Policy-level multisig possible | Chain VM + gas + governance | Upgrade/admin compromise |
| On-chain multisig of PQ keys | New output/account | Coarse m-of-n | PQ opcode/account validation | Large witness and visible policy |
| Threshold ML-DSA research | Potentially ordinary PQ signature | Research / emerging | Scheme support + mature implementation | Rejection sampling/MPC complexity |
| Stateful hash-based threshold | Scheme dependent | Operationally hazardous | State tracking | Backup rollback / one-time-key reuse |
Draft Pay-to-Merkle-Root removes Taproot's exposed key path and targets long-exposure resistance while retaining script trees.
Concrete use: Track status and wallet/test-vector work; do not label current holdings P2MR.
Failure mode: A merged BIP document is not activated consensus.
Draft informational migration/sunset framework discusses restricting legacy vulnerable outputs after a future PQ output exists.
Concrete use: Use it to model governance choices and legacy-coin policy, not a schedule.
Failure mode: Draft phase names and dates are not network commitments.
A contract/account validation layer can make signature verification upgradeable without changing the user-facing account.
Concrete use: Inventory upgrade authority, fallback path, validation gas and chain support.
Failure mode: Upgradability trades cryptographic rigidity for governance risk.
Freeze, rescue/burn, and do-nothing positions allocate theft, property and consensus risk differently.
Concrete use: Represent the debate in board risk planning; do not assume an outcome.
Failure mode: Custodians cannot unilaterally choose chain consensus.
Planning inequality: required secrecy lifetime + migration duration > uncertain time to capability means inventory and agility work starts now—even when scheme replacement is blocked.
| When | Control | Owner | Evidence | Blocked by |
|---|---|---|---|---|
| Now | Inventory chain, scheme, output/account type, exposure, value and horizon | Custody engineering | Versioned cryptographic asset register | Nothing |
| Now | Ban address reuse and protect xpub/descriptor exports | Wallet platform | Policy test + monitoring | Nothing |
| Now | Sweep reused/exposed long-held outputs where ordinary risk permits | Custody operations | Approved migration/reconciliation | Fees and operational risk |
| Now | Record software, path, scheme, signer, export and recovery metadata | Platform + DR | Restore-tested inventory | Vendor access may limit |
| Now | Ask vendor for PQ roadmap and independent export/re-key path | Risk/procurement | Written response + exit test | Vendor capability |
| Next | Make signature scheme and serialization explicit in internal interfaces | Architecture | Multi-scheme test harness | Legacy assumptions |
| Next | Model byte/fee/capacity impact and migration batching | Chain operations | Scenario workbook | Final chain rules unknown |
| Next | Monitor NIST MPTC and chain proposals by status | Cryptography owner | Quarterly review | Standards/governance |
| Later | Deploy PQ or hybrid signing | Chain + custodian | Activated standard path + audited implementation | Consensus and mature threshold support |
Calm inventory work is useful under every forecast. Panic procurement is useful under none.
Decision inequality: required security lifetime + credible migration duration versus an uncertain capability horizon. Uncertainty motivates reversible inventory work, not false precision.
| Timeline | What is factual | What remains uncertain | Planning use |
|---|---|---|---|
| NIST transition | IR 8547 initial public draft describes federal transition planning | Draft may change; application guidance differs | Track status and agency-specific mandates |
| NIST standards | FIPS 204/205 final since August 2024 | Blockchain consensus and threshold profiles | Use parameters for size/testing, not deployment claims |
| NIST threshold work | IR 8214C final January 2026; submissions/workshops active | Mature audited custody interoperability | Review annually; prototype off production path |
| Bitcoin proposals | BIPs 360/361 are Draft as of August 2026 | Activation, signature choice, sunset policy, schedule | Inventory dependencies; promise no date |
| CRQC capability | No public machine breaks production ECC today | Whether/when capability exists | Use scenario ranges, not a forecast year |
Operational and volatile claims were checked against these first-party documents on 2026-08-31. Examples are illustrative controls, not legal, investment, or vendor-selection advice.