Hybrid Post-Quantum Signatures for Bitcoin and Ethereum: A Protocol-Level Integration Strategy

1. Introduction

The development of cryptographically relevant quantum computers poses an urgent threat to blockchain security. Current research indicates that breaking secp256k1 requires dramatically fewer resources than previously thought. The author’s derivation shows that using the formula Q_L = 2⌈log₂(n)⌉+2+⌈log₂(2+1/(2ε))⌉, an algorithmic logical-qubit lower bound for a canonical Shor/phase-estimation circuit [1], with ε = 0.001, yields 523 logical qubits for secp256k1 [71]. Conservative estimates based on comprehensive resource models place the requirement at up to 2,500 logical qubits [1,66,67]. Dallaire-Demers et al. (2025) provide explicit logical-to-physical mappings for secp256k1 under various code families, showing that breaking full 256-bit ECDSA could be feasible with 10⁵–10⁶ high-quality physical qubits [63]. This represents a significant reduction from the 2,100–2,400 logical qubits estimated for standard NIST curves [1,2].

Importantly, this threshold is not static. While hardware improvements reduce time-to- threat, algorithmic developments work both ways: quantum algorithms may improve (reducing required qubits further), classical optimization of PQC may improve (reducing performance penalties), error correction improvements could accelerate or decelerate timelines, and new quantum-resistant algorithms may emerge. The 523–2,500 qubit range itself reflects this al- gorithmic uncertainty, with a 5× variance in estimates [33,34,35]. Current surface code error correction requires approximately 1,000 physical qubits per logical qubit [64], though emerging LDPC and cat code architectures promise significant improvements [62,68]. With conservative surface codes, 10⁵ physical qubits yield ∼100 logical qubits, while 10⁶ physical qubits provide ∼1,000 logical qubits—placing secp256k1’s vulnerability threshold firmly within reach. IBM’s roadmap projecting 500–1,000 logical qubits by 2029 [3] places the critical threshold within reach.

Additionally, secp256k1 is not officially approved by NIST for federal use under current standards like FIPS 186-5 [59] or SP 800-186 [60], creating a dual vulnerability: quantum susceptibility and regulatory non-compliance.

Moreover, secp256k1’s rigid parameters that enable efficient implementation also create clas- sical attack surfaces—including timing attacks and differential fault attacks that apply to elliptic curves generally [57,58]—that could be exploited in hybrid classical-quantum attacks, poten- tially reducing the effective quantum resistance below even the lower bound of the 523–2,500 qubit range.

However, this accelerated technical timeline collides with an equally daunting governance challenge. Historical blockchain governance demonstrates that even beneficial upgrades require 2–5+ years for implementation and adoption. SegWit, offering clear capacity benefits, required 20 months for activation (December 2015 to August 2017) and achieved only ∼50% adoption by late 2020—five years post-activation [26,69]. The block size debate (2015–2017) resulted in the Bitcoin Cash fork rather than consensus after 2.5 years of deadlock [70]. Even Taproot, facing minimal controversy with broad support, required 22 months for activation (January 2020 to November 2021) [41].

These were upgrades offering tangible benefits. PQC migration represents an unprecedented ‘defensive downgrade’—imposing severe costs (50% capacity loss, 2–3× fees) with zero immediate benefits. No historical precedent exists for voluntary adoption of purely costly changes. Given that beneficial changes required 2–5+ years, projecting 10–15 years for a defensive downgrade is conservative, not pessimistic.

Recent analyses by Aggarwal et al. [4], Mosca [5], and Bernstein & Lange [6] demon- strate that quantum vulnerability varies dramatically by blockchain architecture. Bitcoin’s UTXO model leaves approximately 25% of total supply (4–6 million BTC) immediately vulner- able through P2PK addresses and reused P2PKH/P2WPKH addresses [4]. Ethereum’s account model exposes a significant portion of circulating ETH due to persistent address reuse, though exact percentages vary by methodology [7]. Solana and Ed25519-based chains face near-complete vulnerability as public keys are directly used as addresses [8,9].

The specific analysis of secp256k1 reveals a more urgent timeline than general elliptic curve estimates. The author derives that secp256k1 could break with approximately 523 logical qubits (an algorithmic lower bound for a canonical Shor/phase-estimation circuit, not inclusive of arithmetic and ancilla) using Q_L = 2(256) + 2 + 9 = 523 for error probability ε = 0.001 [71] The author derives 523 logical qubits as an algorithmic logical-qubit lower bound (not inclusive of arithmetic and ancilla qubits) for a canonical Shor/phase-estimation circuit using QL = 2⌈log2(n)⌉ + 2 + ⌈log2(2 + 1/(2ε))⌉ with ε = 0.001. For secp256k1: QL = 2(256) + 2 + 9 = 523, where ⌈log2(502)⌉ = 9. Conservative estimates range up to 2,500 logical qubits based on comprehensive resource models [1,66,67]. The 5× variance (523 to 2,500) highlights fundamental uncertainty in quantum threat timelines., while conservative estimates based on comprehensive resource models place the requirement at up to 2,500 logical qubits [1,66,67], still substantially below the 2,100–2,400 estimated for standard NIST curves [1,2]. Even at the higher estimate of 2,500 logical qubits, IBM’s roadmap projecting 500–1,000 logical qubits by 2029 [3] places the threat within a decade—far shorter than the governance timeline required for migration.

Figure 1. Realistic Quantum Computing Threat Timeline - secp256k1 Specific.

Figure 1. Realistic Quantum Computing Threat Timeline - secp256k1 Specific.

Stewart et al. [10] identify real-time attacks during transaction broadcast. With secp256k1’s vulnerability range of 523–2,500 logical qubits, attack time of 16.8 seconds is calculated based on the author’s 523-qubit lower bound derivation assuming 1µs gate time [71], while conservative estimates up to 2,500 qubits suggest longer attack times [1,66,67], with timing methodologies discussed in [75], with the optimistic scenario fitting within Bitcoin’s 10-minute blocks and marginally within Ethereum’s 12-second blocks.

This paper bridges the gap between technical necessity and political reality by presenting: (1) empirical performance data from permissioned systems showing measurable throughput degra- dation [15], with explicit analysis of why permissionless networks will likely experience 30–50% worse impacts; (2) state bloat analysis revealing 59× permanent storage increase per quantum- resistant account (calculated as 1,952 bytes / 33 bytes for ML-DSA-65); (3) governance reality acknowledging that defensive downgrades face fundamentally different political dynamics, with historical evidence; (4) crypto-agility framework enabling algorithm flexibility to avoid lock-in risks; and (5) honest timeline assessment presenting the collision between the 4–10 year quantum threat and 10–15 year governance reality based on documented precedents.

2. Methodology

2.1. NIST-Standardized Post-Quantum Signatures

The NIST Post-Quantum Cryptography standardization process concluded in 2024 with three primary signature schemes [11]. CRYSTALS-Dilithium (ML-DSA) uses module lattice-based construction with Fiat-Shamir with aborts [12], serving as NIST’s primary recommendation for general use under FIPS 204 [11]. It offers straightforward implementation without floating-point arithmetic across three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87.

FALCON (FN-DSA) employs NTRU lattice-based construction using the Gentry-Peikert- Vaikuntanathan framework [13], providing the smallest signatures among lattice schemes. Cur- rently proceeding as FIPS 206 (draft status), it requires complex implementation with floating-point and Gaussian sampling, with performance varying 6–8× depending on the hardware FPU availability [12].

SPHINCS+ (SLH-DSA) provides a hash-based, stateless construction [14] with the most conservative security assumptions, standardized under FIPS 205, requiring only hash function security [31]. It suffers from large signatures and slow operations despite multiple parameter sets balancing size versus speed [28].

2.2. Current Implementation Status and Performance Impact

Table 1. Actual Implementation Status Across Blockchain Projects.

Project	Claimed Sta- tus	Actual Reality	Performance Data	Relevance to Mi- gration
Hyperledger Fabric	“Production ready”	Testnet experi- ments only	∼7.5% certificate generation increase, ∼1.8× latency [15]	Limited— permissioned only
Ethereum [19,38]	“Active re- search”	Proposals and dis- cussions	Unknown—not imple- mented	Years from deploy- ment
Bitcoin [20]	“Community debate”	Early proposal stage	Unknown—no consen- sus	No timeline estab- lished
Various PQC-native chains	“Live mainnet”	New chains, no mi- gration	N/A—built from scratch	Not migration ex- amples

Table 1. Actual Implementation Status Across Blockchain Projects.

Project	Claimed Sta- tus	Actual Reality	Performance Data	Relevance to Mi- gration
Hyperledger Fabric	“Production ready”	Testnet experi- ments only	∼7.5% certificate generation increase, ∼1.8× latency [15]	Limited— permissioned only
Ethereum [19,38]	“Active re- search”	Proposals and dis- cussions	Unknown—not imple- mented	Years from deploy- ment
Bitcoin [20]	“Community debate”	Early proposal stage	Unknown—no consen- sus	No timeline estab- lished
Various PQC-native chains	“Live mainnet”	New chains, no mi- gration	N/A—built from scratch	Not migration ex- amples

Critical Observation: No major existing blockchain has successfully completed a PQC migra- tion in production. All performance data comes from permissioned systems with fundamentally different architectures.

The reliance on Hyperledger Fabric data represents a critical methodological limitation. Available studies measure PQC impact in controlled, permissioned environments with known validators, homogeneous hardware, and optimized batching [15,16]. Kasula et al. report ∼7.5% certificate generation increase and ∼1.8× transaction latency for L-PQC integration in Fabric [15]. Zhukabayeva et al. demonstrate measurable throughput impacts that vary significantly based on signature scheme and system parameters [16].

Methodology Note: These permissioned testbeds differ fundamentally from permission- less networks. Fabric experiments typically use: (1) controlled block sizes (2–10 MB), (2) known endorsement policies with 3–5 validators, (3) homogeneous hardware (identical nodes), (4) opti- mized batch verification, and (5) local or regional networks with sub-100ms latency. In contrast, permissionless networks face: (1) global propagation across 10,000+ heterogeneous nodes [72,73], (2) adversarial conditions requiring additional validation, (3) no batching optimization for individual miners, and (4) economic incentives that resist capacity reduction.

Based on these structural differences, the author models 70–80% throughput loss for permis- sionless networks—a conservative extrapolation given the compounding effects of larger signa- tures on global propagation times. This represents the author’s analytical model, not empirical measurement, as no direct permissionless PQC performance data exists in the literature:

Table 2. Available PQC Performance Data.

Metric	Source	Finding	System Context
Certificate Generation	Kasula et al. [15]	+7.5% time	Hyperledger Fabric test
Transaction Latency	Kasula et al. [15]	∼1.8×	L-PQC integration
Throughput	Zhukabayeva et al. [16]	Variable reduction	Depends on parameters
Permissionless Impact	No empirical data	Author projects 70–80% loss	Analytical model only

Note: No comprehensive permissionless blockchain PQC performance studies exist. Extrap- olations are speculative.

Table 2. Available PQC Performance Data.

Metric	Source	Finding	System Context
Certificate Generation	Kasula et al. [15]	+7.5% time	Hyperledger Fabric test
Transaction Latency	Kasula et al. [15]	∼1.8×	L-PQC integration
Throughput	Zhukabayeva et al. [16]	Variable reduction	Depends on parameters
Permissionless Impact	No empirical data	Author projects 70–80% loss	Analytical model only

Note: No comprehensive permissionless blockchain PQC performance studies exist. Extrap- olations are speculative.

Conservative permissionless impact estimates suggest significantly worse performance than measured in permissioned systems, but remain speculative without empirical data.

2.3. Algorithm Comparison and Implementation Reality

Table 3. Comprehensive Algorithm Metrics and Implementation Challenges.

Algorithm	Security Level	Public Key (bytes)	Signature (bytes)	Verify (cycles)	Implementation Reality	NIST Status
ECDSA (secp256k1)	128-bit classical	33	71	∼80,000	Mature, universal support [43]	Not in FIPS 186-5 or SP 800-186 [59,60]
ML-DSA-44 [12]	NIST Level 2	1,312	2,420	∼327,000	Moderate complex- ity, recommended	FIPS 204 [11]
ML-DSA-65 [12]	NIST Level 3	1,952	3,309	∼522,000	Good security/size balance	FIPS 204 [11]
ML-DSA-87 [12]	NIST Level 5	2,592	4,627	∼696,000	Maximum security, larger	FIPS 204 [11]
FN-DSA-512 [13]	NIST Level 1	897	666	∼353,000*	Complex, potential side-channel risks [76]	FIPS 206 (draft)
FN-DSA-1024 [13]	NIST Level 5	1,793	1,280	∼700,000*	Very complex, few implementations	FIPS 206 (draft)

*Performance varies 6–8× depending on hardware FPU availability. Note: While [76] specifically studied BLISS, similar lattice-based schemes like FALCON may share vulnerability patterns

Table 3. Comprehensive Algorithm Metrics and Implementation Challenges.

Algorithm	Security Level	Public Key (bytes)	Signature (bytes)	Verify (cycles)	Implementation Reality	NIST Status
ECDSA (secp256k1)	128-bit classical	33	71	∼80,000	Mature, universal support [43]	Not in FIPS 186-5 or SP 800-186 [59,60]
ML-DSA-44 [12]	NIST Level 2	1,312	2,420	∼327,000	Moderate complex- ity, recommended	FIPS 204 [11]
ML-DSA-65 [12]	NIST Level 3	1,952	3,309	∼522,000	Good security/size balance	FIPS 204 [11]
ML-DSA-87 [12]	NIST Level 5	2,592	4,627	∼696,000	Maximum security, larger	FIPS 204 [11]
FN-DSA-512 [13]	NIST Level 1	897	666	∼353,000*	Complex, potential side-channel risks [76]	FIPS 206 (draft)
FN-DSA-1024 [13]	NIST Level 5	1,793	1,280	∼700,000*	Very complex, few implementations	FIPS 206 (draft)

*Performance varies 6–8× depending on hardware FPU availability. Note: While [76] specifically studied BLISS, similar lattice-based schemes like FALCON may share vulnerability patterns

The choice between FALCON and Dilithium creates a no-win scenario: FALCON risks catastrophic implementation vulnerabilities and side-channel attacks despite smaller signatures, while Dilithium guarantees permanent network degradation from 47× larger signatures. No “magic bullet” algorithm exists that solves both problems.

3. Results

3.1. Hybrid Signature Architecture

Our hybrid signature approach acknowledges four realities: backward compatibility with exist- ing ECDSA infrastructure [39,40], forward security through quantum resistance [10], graceful degradation if one algorithm fails [23], and acceptance of severe, unavoidable performance penal- ties [15].

The technical specification employs a hybrid signature structure:

Total sizes:

• With ML-DSA-44: 2,531 bytes (35.6× ECDSA)
• With ML-DSA-65: 3,420 bytes (48.2× ECDSA)
• With ML-DSA-87: 4,738 bytes (66.7× ECDSA)
• With FN-DSA-512: 777 bytes (10.9× ECDSA)

Security analysis shows that against classical adversaries, security equals the maximum of ECDSA and PQC security (128–256 bits). Against quantum adversaries, ECDSA breaks with 523–2,500 logical qubits for secp256k1 [1,66,67,71], leaving security dependent solely on the PQC component. Hybrid signatures provide insurance against algorithmic failure, not multi- plicative security [23].

3.2. State Bloat and Permanent Costs

Beyond transient transaction impacts, PQC creates permanent, compounding state growth. Bit- coin’s UTXO set would expand from ∼5 GB to ∼296 GB with ML-DSA-65, a 59.2× permanent increase per output (calculated as 1,952-byte public keys / 33-byte current keys = 59.2×) that cannot be pruned without breaking verification. Ethereum faces similar challenges, as EOA accounts transition from 33-byte to 1,952-byte public keys, resulting in cumulative growth exceeding 1 TB of additional permanent state within five years.

This results in severe consequences of centralization: sync time increases from days to weeks, storage requirements grow from 1 TB to 5–10 TB, and bandwidth needs increase 10 times during sync, resulting in 50–80% of current nodes being priced out [74]. This creates a death spiral where centralization begets more centralization.

3.3. Capacity Analysis and Optimization Potential

Current empirical measurements from permissioned systems:

Table 4. Transaction Size Impact of PQC.

Metric	Current ECDSA	With ML-DSA-65	Impact
Public Key Size	33 bytes	1,952 bytes	59× increase
Signature Size	71 bytes	3,309 bytes	47× increase
Typical Transaction	∼250 bytes	∼2,800 bytes	11× increase
State Storage per Account	33 bytes	1,952 bytes	59× permanent increase

Note: Size increases are algorithmic properties of the signature schemes. Network perfor- mance impacts require empirical testing on specific blockchain implementations.

Table 4. Transaction Size Impact of PQC.

Metric	Current ECDSA	With ML-DSA-65	Impact
Public Key Size	33 bytes	1,952 bytes	59× increase
Signature Size	71 bytes	3,309 bytes	47× increase
Typical Transaction	∼250 bytes	∼2,800 bytes	11× increase
State Storage per Account	33 bytes	1,952 bytes	59× permanent increase

Note: Size increases are algorithmic properties of the signature schemes. Network perfor- mance impacts require empirical testing on specific blockchain implementations.

Permissionless extrapolation suggests a 30–40% capacity retention versus measured performance in permissioned systems, with the potential for worse degradation under adversarial conditions.

Table 5. Optimization Techniques and Realistic Impact.

Technique	Description	Capacity Gain	Status	Confidence
Batch Verification [23]	Verify multiple sigs to- gether	+15–20%	Implemented	High (85%)
Segregated Witness Style [26]	Move PQC to exten- sion block	+20–25%	Proven con- cept	High (80%)
Selective Deploy- ment	Only high-value needs PQC	+10–15%	Easy to im- plement	High (90%)
State Compression	Merkle proofs for old state	Storage only	Complex	Medium (60%)
Combined Real- istic Impact	All proven techniques	50–60% re- tention	Achievable	Medium (65%)

Table 5. Optimization Techniques and Realistic Impact.

Technique	Description	Capacity Gain	Status	Confidence
Batch Verification [23]	Verify multiple sigs to- gether	+15–20%	Implemented	High (85%)
Segregated Witness Style [26]	Move PQC to exten- sion block	+20–25%	Proven con- cept	High (80%)
Selective Deploy- ment	Only high-value needs PQC	+10–15%	Easy to im- plement	High (90%)
State Compression	Merkle proofs for old state	Storage only	Complex	Medium (60%)
Combined Real- istic Impact	All proven techniques	50–60% re- tention	Achievable	Medium (65%)

Table 6. Speculative Technologies - Research Goals Only.

Technology	Theoretical Benefit	Current Status	Timeline	Success Probability
PQC Signature Ag- gregation [23]	60–80% size re- duction	Mathematical proposals only	3–5 years R&D	¡30%
STARK Compres- sion [49,52]	10× compres- sion possible	Concept only, no prototypes	5–7 years R&D	¡20%
Hardware Accelera- tion	3–5× faster ver- ification	Early re- search	3–4 years	50%
If All Succeed	70–80% ca- pacity	Not a real- istic plan- ning basis	7–10 years	¡15%

Table 6. Speculative Technologies - Research Goals Only.

Technology	Theoretical Benefit	Current Status	Timeline	Success Probability
PQC Signature Ag- gregation [23]	60–80% size re- duction	Mathematical proposals only	3–5 years R&D	¡30%
STARK Compres- sion [49,52]	10× compres- sion possible	Concept only, no prototypes	5–7 years R&D	¡20%
Hardware Accelera- tion	3–5× faster ver- ification	Early re- search	3–4 years	50%
If All Succeed	70–80% ca- pacity	Not a real- istic plan- ning basis	7–10 years	¡15%

Figure 2. Capacity Retention Projected Ranges.

Figure 2. Capacity Retention Projected Ranges.

3.4. Deployment Challenges and Governance Reality

Unlike every previous blockchain upgrade, PQC migration represents a defensive downgrade imposing immediate, severe costs with zero tangible benefits.

Table 7. The “Pain vs. Gain” Asymmetry with Historical Evidence.

Table 7. The “Pain vs. Gain” Asymmetry with Historical Evidence.

The timeline crisis specific to secp256k1 creates an impossible situation. The quantum threat requires only 523–2,500 logical qubits, with the author’s calculation yielding 523 using Q_L = 2(256) + 2 + 9 (an algorithmic lower bound) [71] and conservative estimates up to 2,500 qubits [1,66,67], with IBM achieving potentially 500–1000 logical qubits by 2029 and 2,500+ by 2033 [3], arriving in 4–10 years. Migration reality requires consensus building (5–10 years minimum based on historical precedent), implementation and deployment (2–3 years), and user migration (2–3 years), totaling 10–15 years. This creates a gap where migration takes longer than available time even in optimistic scenarios.

Table 8. Bitcoin Deployment Approaches with Realistic Timelines.

Approach	Method		Political Fea- sibility		Realistic Timeline	vs. 2029 Threat
Soft Fork (BIP- 360 draft) [20]	P2QRH output type		Low change, merged)	(costly un-	5–10 years	Too Late
Hard Fork	Clean imple- mentation		Very Low (split risk + costs)		10+ years or never	Too Late
Extension Blocks	Parallel chain	PQC	Medium plexity)	(com-	7–12 years	Too Late
Layer 2 Only	Lightning PQC	+	High (no L1 change)		2–3 years (incomplete)	Partial

Table 8. Bitcoin Deployment Approaches with Realistic Timelines.

Approach	Method		Political Fea- sibility		Realistic Timeline	vs. 2029 Threat
Soft Fork (BIP- 360 draft) [20]	P2QRH output type		Low change, merged)	(costly un-	5–10 years	Too Late
Hard Fork	Clean imple- mentation		Very Low (split risk + costs)		10+ years or never	Too Late
Extension Blocks	Parallel chain	PQC	Medium plexity)	(com-	7–12 years	Too Late
Layer 2 Only	Lightning PQC	+	High (no L1 change)		2–3 years (incomplete)	Partial

Table 9. Ethereum Deployment Strategies with Reality Check.

Strategy	Implementation	Gas Cost	Realistic Timeline	vs. 2029 Threat
AA/ERC-4337	Smart contract wallets	3–5× current	Available but expen- sive	Possible
EIP-7701 (Draft) [38]	Native AA sup- port	2–3× current	3–5 years	Tight
Protocol Change	New transaction type	1.5–2× cur- rent	5–8 years	Too Late
State Migration	Replace all keys	One-time massive	10+ years	Too Late

Table 9. Ethereum Deployment Strategies with Reality Check.

Strategy	Implementation	Gas Cost	Realistic Timeline	vs. 2029 Threat
AA/ERC-4337	Smart contract wallets	3–5× current	Available but expen- sive	Possible
EIP-7701 (Draft) [38]	Native AA sup- port	2–3× current	3–5 years	Tight
Protocol Change	New transaction type	1.5–2× cur- rent	5–8 years	Too Late
State Migration	Replace all keys	One-time massive	10+ years	Too Late

Table 10. Why Consensus is Nearly Impossible.

Stakeholder	Incentive	Likely Action	Result
Miners/Validators	Maintain revenue	Resist capacity reduction	Delay
Exchanges	Avoid costs	Wait for others to move	Delay
Users	Low fees	Oppose fee increases	Delay
Developers	Technical perfection	Endless optimization	Delay
Nobody	Wants immediate pain	Everyone waits	Stalemate

Table 10. Why Consensus is Nearly Impossible.

Stakeholder	Incentive	Likely Action	Result
Miners/Validators	Maintain revenue	Resist capacity reduction	Delay
Exchanges	Avoid costs	Wait for others to move	Delay
Users	Low fees	Oppose fee increases	Delay
Developers	Technical perfection	Endless optimization	Delay
Nobody	Wants immediate pain	Everyone waits	Stalemate

Figure 3. Bitcoin PQC Migration - Collision with Reality.

Figure 3. Bitcoin PQC Migration - Collision with Reality.

3.5. Implementation Challenges and Crypto-Agility

Table 11. Hidden Implementation Challenges.

Challenge	Description		Impact		Mitigation
Key Manage- ment	Users need 2+ key pairs		UX mare	night-	Years of wallet updates
Recovery Phrases	Longer needed	seeds	Incompatible standards		Fragmentation
Hardware Wal- lets	Limited ory/CPU	mem-	Many come lete	be- obso-	Forced upgrades
Cross-chain	Different choices	PQC	Bridge incompati- bility		Ecosystem frac- ture
Smart Con- tracts	Gas limits exceeded		Many come able	be- unus-	Forced rewrites

Table 11. Hidden Implementation Challenges.

Challenge	Description		Impact		Mitigation
Key Manage- ment	Users need 2+ key pairs		UX mare	night-	Years of wallet updates
Recovery Phrases	Longer needed	seeds	Incompatible standards		Fragmentation
Hardware Wal- lets	Limited ory/CPU	mem-	Many come lete	be- obso-	Forced upgrades
Cross-chain	Different choices	PQC	Bridge incompati- bility		Ecosystem frac- ture
Smart Con- tracts	Gas limits exceeded		Many come able	be- unus-	Forced rewrites

Current proposals hard-coding specific algorithms create future risk given recent failures (Rain- bow, SIKE, GeMSS). Crypto-agility enables algorithm flexibility:

Table 12. Timeline vs. Threat Analysis - secp256k1 Range.

Scenario	Migration Needs	Threat Arrives (523- 2,500 qubits)	Outcome
Optimistic	5–7 years (start 2025)	2029–2033	Tight to feasible
Realistic	10–15 years (start 2025)	2029–2033	Too late
With Algo Im- provements	10–15 years	2028–2032	Far too late
With Crisis Delay	Start 2030+	2029–2033	Catastrophi

Table 12. Timeline vs. Threat Analysis - secp256k1 Range.

Scenario	Migration Needs	Threat Arrives (523- 2,500 qubits)	Outcome
Optimistic	5–7 years (start 2025)	2029–2033	Tight to feasible
Realistic	10–15 years (start 2025)	2029–2033	Too late
With Algo Im- provements	10–15 years	2028–2032	Far too late
With Crisis Delay	Start 2030+	2029–2033	Catastrophi

4. Conclusion

The secp256k1 vulnerability to 523–2,500 logical qubits, with the author deriving 523 qubits as an algorithmic lower bound through Q_L = 2(256) + 2 + 9 = 523 [71] and conservative estimates up to 2,500 qubits [1,66,67], combined with IBM’s quantum roadmap projecting 500–1,000 qubits by 2029 and potentially 2,500+ by 2033 [3], creates a crisis that governance may not address in time. The evidence demonstrates that while technical solutions exist, they impose severe costs including major throughput reduction (50–70% based on permissioned data, potentially worse in permissionless networks), 59× state bloat (1,952 bytes / 33 bytes for ML- DSA-65), and 5–10× node requirements (projection based on storage and bandwidth increases). The timeline reality shows 4–10 years available (depending on which end of the 523–2,500 range proves accurate) versus 10–15 years needed for migration based on historical governance patterns, creating significant risk even with conservative estimates.

Three scenarios emerge, ordered by historical precedent:

• Crisis-Driven Migration (Most Likely): Governance stalemate until quantum ca- pabilities become undeniable (2027–2029), forcing emergency action. Evidence: Every major Bitcoin upgrade required either crisis (SegWit/UASF) or minimal controversy (Taproot).
• Migration Failure (Significant Risk): Inability to achieve consensus before quantum threshold. Evidence: Block size debate ended in chain split rather than resolution after 2.5 years.
• Proactive Migration (Least Likely): Coordinated action before visible threat. Evi- dence: No historical precedent for voluntary defensive downgrades in blockchain governance.

Rather than assign unverifiable probabilities, we note that historical patterns strongly favor delayed, crisis-driven responses.

The blockchain community must acknowledge secp256k1’s 523–2,500 qubit vulnerability range publicly, implement crypto-agility as crisis infrastructure immediately, conduct permis- sionless testing urgently to stop extrapolating from Hyperledger, quantify state bloat impacts accurately (59× for ML-DSA-65), and prepare for potential forced migration by 2029–2033. We must stop pretending we have 10–15 years when secp256k1 gives us 4–10 years at most, that optimizations will save us, or that governance will be smooth.

The choice of secp256k1, optimal in 2008, becomes potentially catastrophic by 2029–2033. Blockchain’s decentralized governance faces severe challenges responding to this deadline requir- ing coordinated sacrifice. We are observing a developing situation where the specific vulnerabil- ity of secp256k1 may ensure the threat arrives before adequate solutions can be implemented. Every month of delay reduces the probability of successful migration. The window is rapidly narrowing—for secp256k1, decisive action is urgently needed.