Bitcoin's post-quantum problem becomes much harder when governance timelines and hardware timelines begin to converge.
The first article in this series laid out the infrastructure problem: BIP 360 needs at minimum seven years. Full PQC signature integration, realistically ten to twelve. CRQC estimates cluster around 2035–2040. The timelines overlap, and the margin is thin or zero. If quantum hardware outpaces community coordination by even two or three years, there's a window where Bitcoin funds in vulnerable formats are exposed with no protocol-level defense.
This article asks a different question. Not how to fix Bitcoin's protocol — that work is necessary and ongoing — but what intermediate architecture could serve as a holding pattern while the base layer catches up. Not a permanent replacement. A structured shelter.
I'll describe the architecture, explain where its assumptions hold, say where they don't, and be specific about what remains unresolved. This is a design direction, not a finished protocol.
The Migration Gap
I've spent enough time tracking Bitcoin governance to know the base rate. SegWit: three years, including a community war. Taproot: two years, relatively smooth. Block size debate: four-plus years, chain split.
Post-quantum migration is harder than any of those. Heilman estimates seven years for BIP 360 alone. Full PQC opcodes and signature support — longer. And the social coordination problem is worse this time, because the threat is abstract until the day it isn't. Classic collective action failure: everyone knows migration is needed, nobody feels urgency until urgency means panic.
Institutions holding large positions, custodians managing client assets, bridge operators securing locked reserves — these actors face concentrated risk during the gap. The standard answer is "accelerate migration." That's correct. But it assumes the coordination problem can be solved on a timeline dictated by physics. Bitcoin's track record suggests otherwise.
A backup plan doesn't need to be elegant. It needs to be architecturally sound, honest about its limitations, and deployable without requiring Bitcoin consensus changes.
The Architecture
It starts on the Bitcoin side. The bridge operates a P2WSH address — SHA-256 based, offering roughly a 128-bit post-quantum security margin against Grover's algorithm, stronger than P2WPKH's HASH160 at approximately 80 bits. This address only receives BTC. The public key sits behind a hash. As long as it never initiates an outgoing transaction, the key never appears on-chain. Shor's algorithm needs the key. A hash gives it nothing.
That's the critical constraint. The Bitcoin-side address is deliberately non-spending. Deposit vault, not active wallet. The moment it spends, the key shows up in witness data and the on-spend window opens. So the design says: don't spend. I've written about bridge custody mechanics — how key management drives the entire security model. Here the decision is radical: eliminate the spending path entirely.
On the other side of the bridge, a STARK-based execution environment issues a wrapped BTC token backed 1:1 by the locked deposit. Transfers, DeFi interaction, whatever the environment supports — the user operates with the wrapped token.
Why STARK specifically? The proof system is hash-based, not curve-based. The canonical STARK paper is titled Scalable, Transparent, and Post-Quantum Secure Computational Integrity. SNARKs, PLONK, Groth16 — all rely on elliptic curve pairings, all vulnerable to Shor's algorithm. STARKs derive their integrity guarantees from collision-resistant hash functions instead. Different mathematical foundation, different quantum profile.
Google's 2026 whitepaper reinforces this distinction: in its analysis of value secured across scaling protocols, the paper notes that SNARK-based systems carry curve-based assumptions vulnerable to quantum key derivation. STARK-based systems do not rely on those same curve-pairing assumptions at the proof layer.
This matters at the proof layer. But it's important to be precise about what it does and doesn't mean for the full operational stack. A STARK-based proof system gives the execution environment a stronger quantum posture at the verification layer than any curve-based alternative. It does not, by itself, make the entire network post-quantum. Sequencers, bridge validators, RPC infrastructure, and user-facing signing all carry their own cryptographic dependencies. The proof layer is one surface — a critical one, but not the only one.
The third layer is account-level signatures. Through account abstraction — which networks like Starknet already support — user accounts can in principle run custom validation logic, including post-quantum signature algorithms. This creates an upgrade path: hash-based proofs underneath, PQC-capable signatures on top. Whether a given deployment has actually implemented and activated PQC account signatures is a separate question from whether the architecture permits it. The distinction between capability and deployment matters here.
Put it together: BTC locked on Bitcoin behind a hash-protected key that is never revealed. Wrapped representation on a network where the proof layer uses hash-based cryptography and the account layer has an architectural path to post-quantum signatures. The value can remain economically represented, and users can preserve operational utility on the far side of the bridge, without requiring immediate Bitcoin consensus changes.
I've been calling this "quantum parking."
Why One-Way Is the Security Feature, Not a Limitation
Every existing wrapped BTC model — wBTC, cbBTC, tBTC — is built for two-way operation. Deposit, receive wrapped tokens, redeem back. Redemption requires the custodian to spend from the Bitcoin reserve address. Spending reveals the public key. In a post-quantum world, that's an attack window.
I covered this problem in the first article: wrapped BTC fails on both sides because every rebalancing operation creates on-spend exposure. The two-way design that makes wBTC useful today becomes a vulnerability when the signature layer is threatened.
A two-way bridge in a quantum environment faces a dilemma: either the reserve keys are quantum-safe (requiring Bitcoin PQC consensus changes that don't exist), or every redemption is an exposure event. No clean solution within current Bitcoin rules.
The one-way design sidesteps this entirely. By committing upfront that the Bitcoin-side address will not spend, the architecture eliminates the on-spend vector by construction. The address becomes a time capsule — BTC provably there, key hidden, waiting for Bitcoin's protocol to evolve.
One-way pegs aren't new. Drivechain literature describes them. sCrypt has documented trustless one-way peg-in patterns. Robin Linus's BitVM2 bridge paper distinguishes unidirectional bridges from two-way constructions. I've compared bridge models where the one-way/two-way distinction drives the entire risk profile.
What's different here is the security logic behind the constraint. The one-way constraint isn't imposed because we can't build two-way. It's imposed because two-way operation introduces quantum exposure that defeats the shelter's purpose. The constraint is the defense.
The Exit Problem
If the bridge never spends from its Bitcoin address, how do users get BTC back? This is the hard part — and calling it "hard" is generous. It's the part of the architecture that's most honestly unresolved. Three possible paths, each with different assumptions and different levels of readiness.
Scenario A: ZK proof migration. Bitcoin adds a mechanism for proving ownership of a UTXO's private key without revealing the key. The bridge generates a proof — "I control the key behind this hash commitment" — and the protocol accepts it as authorization to move funds into a PQC-safe output.
There is real engineering behind this. Roasbeef, CTO of Lightning Labs, published a proof-of-concept in April 2026: a zk-STARK proof that a Taproot output key was generated via BIP-32/BIP-86 derivation. Proof generation: ~55 seconds on a standard laptop. Verification: under 2 seconds. Size: ~1.7 MB. A separate bitcoindev proposal describes ZK proofs for P2PKH outputs that prove key knowledge without on-chain revelation.
The prototype demonstrates technical feasibility. What it doesn't demonstrate is consensus acceptance. Integrating a new verification primitive into Bitcoin's Script or a new spending path is a consensus change — one that needs community review, security analysis, standardization, and activation. That's a multi-year process with uncertain outcomes. The BIP 360 timeline gives some sense of how long even targeted changes take. A novel ZK-based spending mechanism would likely face steeper scrutiny.
There's also the practical overhead: a 1.7 MB proof per UTXO at current prototype size is substantial relative to Bitcoin's block budget. Proof aggregation could help, but that's additional engineering and standardization work.
Scenario A is the cleanest exit path in theory. In practice, it depends on Bitcoin consensus evolving in a specific and currently uncommitted direction. Promising, but not something an architecture should treat as assured.
Scenario B: Pre-committed PQC script branch. Instead of simple P2WSH, the bridge uses a script with a dormant branch committing to a future PQC public key (hash of PQC key, behind a timelock). Today, the PQC branch is unspendable — Bitcoin consensus doesn't recognize PQC opcodes. When Bitcoin activates PQC support, the bridge activates the dormant branch. Classical key never revealed.
More constrained than Scenario A. Requires foresight at bridge construction. Depends on Bitcoin eventually supporting the specific PQC scheme committed to — a bet on a standard that might not be the one the community adopts. But it only needs PQC opcode activation, which is already on the migration roadmap.
Scenario C: Permanent wrapped representation. BTC stays locked on Bitcoin indefinitely. The wrapped token becomes the operational asset. No exit. Locked BTC functions as permanent backing.
Simplest path. Most philosophically uncomfortable. The value migrated out of Bitcoin's execution environment permanently. The user didn't lose anything — wrapped BTC is liquid, tradeable — but the original BTC is effectively retired. Economically closer to one-way migration than temporary shelter.
The pattern exists at scale. wBTC holds billions in locked BTC that rarely moves. The difference: wBTC promises redemption. Scenario C drops that promise. Whether the market prices "permanently locked backing" at parity with "redeemable backing" is open — I've tracked similar peg dynamics with bridge-wrapped stablecoins, and the answer is usually "no, not at parity, not consistently."
The honest framing: Scenarios A and B offer exit paths that depend on future Bitcoin consensus changes. If those changes arrive, the shelter closes gracefully. If they don't — or they arrive too late, or in a form incompatible with the original script construction — Scenario C becomes the default whether users chose it or not. "Quantum parking" quietly becomes "quantum emigration."
ZK Doesn't Mean Quantum-Safe
An important distinction that most people get wrong, and one that directly affects which execution environment the shelter should target.
Quantum resistance at the proof layer depends on the specific mathematical assumptions, not on whether a system uses "zero knowledge" as a concept. Different ZK systems build on fundamentally different foundations:
| Proof system | Underlying math | Quantum-resistant at proof layer? |
|---|---|---|
| STARKs | Collision-resistant hash functions | Structurally oriented toward quantum resilience |
| SNARKs / PLONK | Elliptic curve pairings | No — vulnerable to Shor |
| Groth16 | Elliptic curves + trusted setup | No — vulnerable to Shor |
A STARK-based environment is better positioned at the proof verification layer than any curve-based alternative. That's a structural property of the math, not a marketing claim.
But proof-layer properties alone don't make an execution environment fully post-quantum in operational practice. The full stack includes sequencers, validators, RPC nodes, user wallets, signature schemes, and bridge infrastructure — each with its own cryptographic surface. A STARK proof system provides a stronger foundation to build on. Whether the rest of the stack actually achieves post-quantum operation depends on implementation choices that are still evolving.
This is why the shelter specifically targets a STARK-based environment — not because such environments are already post-quantum end-to-end, but because they're among the few ZK execution environments where achieving that is architecturally plausible without replacing the proof system itself.
What Makes This Worth Examining
No Bitcoin protocol changes required. Everything on the Bitcoin side uses existing address formats and consensus rules. You can deploy this while the community debates BIP 360. It complements protocol migration rather than competing with it.
The security logic holds at the layers where it matters most. Hash-protected addresses on Bitcoin close the at-rest vector. Hash-based proof systems on the STARK side avoid introducing new curve-based vulnerability at the verification layer. Account abstraction creates an upgrade path for post-quantum signatures at the user level. Each layer addresses a different exposure surface. Whether the operational stack fully realizes these properties depends on implementation — but the architectural direction is coherent.
Removing the spending path eliminates the hardest attack vector by architectural choice. Anyone who's built two-way bridge mechanics knows how much complexity lives in the redemption path. Cut it, and the security model gets simpler.
And the exit scenarios are grounded in real work. Roasbeef's prototype demonstrates that ZK key-ownership proofs are technically viable on Bitcoin-compatible data. The bitcoindev discussions are active. That's real engineering, not speculative sketching — though the distance from "working prototype" to "consensus-accepted spending mechanism" remains substantial.
The Honest Problems
There are real weaknesses in this design, and skipping them would undermine the whole point of this piece.
The bridge trust anchor. Who controls the deposit address keys? Single custodian — concentrated failure point, quantum or not. Multisig committee — each member's key potentially vulnerable under the same ECDSA assumptions the shelter is designed to escape. A trustless bridge on Bitcoin without PQC consensus support is an unsolved problem. The operator set is a trust anchor users must accept, and that's an uncomfortable dependency for an architecture motivated by reducing cryptographic exposure. Removing quantum risk at the key-visibility layer does not remove operational trust at the custody layer. These are different surfaces, and the shelter addresses one while inheriting the other.
The "STARK = quantum-safe" gap. The proof system is hash-based and quantum-oriented. But a live STARK-based network is more than its proof system. Sequencers, bridge validators, and RPC nodes may still run classical cryptography in their operational infrastructure. Account abstraction enables PQC signature upgradeability — but enabling and deploying are different things. Starknet's own documentation acknowledges ongoing work on PQC at the account level. The architecture permits a post-quantum operational stance; it doesn't guarantee one today. Treating the shelter as fully post-quantum end-to-end requires careful qualification.
Liquidity risk. A niche wrapped BTC on a STARK network might trade at a discount to spot BTC. GBTC sat below NAV for years on redemption uncertainty alone. A token with no redemption promise (Scenario C) or uncertain redemption timing (Scenarios A and B) faces the same market pressure. The shelter protects against quantum theft of the underlying BTC. It may not protect against market discounting of the wrapped representation.
The exit problem is genuinely unsolved. Scenarios A and B depend on future Bitcoin consensus changes. Prototypes exist, but prototypes are not consensus. If Bitcoin governance delays PQC integration beyond the CRQC arrival window, Scenario C becomes the default by attrition, not by choice.
What's Original, What Isn't
Intellectual honesty requires this section.
The idea that STARK-based environments offer quantum-resistant properties relevant to Bitcoin value is already publicly articulated by StarkWare. Their CPO released QSB (Quantum-Safe Bitcoin) in April 2026 — quantum-safe transactions using STARK proofs without a soft fork. One-way pegs are a known primitive. ZK key ownership proofs are under active prototyping. PQC script branches are discussed on bitcoindev. None of the building blocks are novel.
What I think is less commonly presented is the specific operational posture: a bridge that deliberately never spends from its Bitcoin address, not as a technical limitation but as a conscious quantum-defense choice, turning the Bitcoin side into a hash-protected time capsule while the STARK side provides operational capability under a post-quantum-oriented architecture. The composition and the framing are the contribution, not the individual parts.
Whether that composition is useful depends on whether the migration gap materializes. If Bitcoin coordinates PQC migration smoothly, quantum parking is unnecessary. If the gap is real and multi-year, this kind of architecture could preserve significant value during the transition.
Scope and Limits
This doesn't replace protocol-level migration. BIP 360, PQC opcodes, community-wide key migration — all necessary regardless. A shelter buys time. It doesn't remove the need for the base-layer upgrade.
It also only helps people who actively use it. Dormant coins, lost keys, anyone not paying attention — they're unprotected. And the design isn't finished. The trust model for bridge operators, specific PQC signature schemes for STARK-side accounts, depeg prevention mechanics, reserve proof oracles — each of these needs rigorous specification that goes well beyond what a design essay can cover.
Other intermediate architectures may prove better. Roasbeef's rescue tool for direct on-chain migration. BIP 360 as a faster partial fix. Custodial PQC vaults. The landscape is moving fast enough that the best answer six months from now might be something nobody has published yet.
Design Direction, Not Destination
Most quantum-risk discussion assumes a binary: either Bitcoin upgrades in time, or it doesn't. The first scenario needs no intermediate architecture. The second is too catastrophic for planning.
There's a third scenario — the realistic one — where timelines are close, the gap is uncertain, and pragmatic intermediate architectures matter. Quantum parking is one such architecture. It uses existing Bitcoin primitives, leverages the structural quantum orientation of hash-based proof systems, and creates a holding pattern that's defensible under a specific threat model while remaining compatible with eventual base-layer migration.
Whether it gets built depends on whether builders assess the migration gap as real enough to justify the trust, liquidity, and complexity costs. That judgment requires watching quantum hardware timelines and Bitcoin's governance velocity with equal attention.
The problem space is real. The architectural direction is coherent. The building blocks already exist in adjacent form. That's enough to make this a serious architectural conversation, not a speculative one.