Source published May 1, 2026, at 22:54 UTC+08:00. This analysis summarizes Paradigm’s original article, “PACTs: Protecting Your Bitcoin From a Quantum Sunset”. PACTs are an illustrative design, not an adopted Bitcoin rescue mechanism.
The research question: can dormant holders prepare without moving coins?
A sufficiently powerful quantum computer could undermine the security of Bitcoin held in outputs with exposed public keys. Paradigm’s article puts the potentially vulnerable holdings at hundreds of billions of dollars, while emphasizing that cryptographically relevant quantum computers, or CRQCs, may remain distant—or never arrive.
One proposed response is a quantum sunset: a protocol upgrade that disables spending from vulnerable outputs. The draft BIP-361 discusses such a soft fork. Its central trade-off is difficult: disabling those spends could prevent quantum theft, but it could also freeze coins belonging to legitimate holders who have remained offline.
Requiring holders to move before a deadline carries its own costs. They must pay transaction fees and publicly reveal activity, potentially exposing wallet relationships, timing patterns or network information. For a dormant early holder, even demonstrating continued access to keys can be a major disclosure.
Provable Address-Control Timestamps, or PACTs, aim to separate preparation from public movement. A holder would privately preserve timestamped evidence of address control now. A future Bitcoin upgrade could then recognize a zero-knowledge proof of that evidence as an alternative route for spending frozen coins.
The distinction is crucial: making the commitment would not require a Bitcoin fork, but honoring it as a rescue mechanism would.
Why existing rescue ideas do not cover every holder
The source describes three broad responses to the quantum risk.
- Do nothing. This could prove appropriate if CRQCs never become practical. If they arrive before protective upgrades, however, attackers could acquire enormous holdings. The article warns that theft on this scale could have geopolitical and regulatory consequences; these are possible outcomes, not established forecasts.
- Sunset vulnerable spending. This could block theft through exposed keys, but holders who miss the migration window could lose access. The source states that Bitcoin did not yet support post-quantum addresses at publication, leaving uncertainty about how much time might separate their introduction from a mandatory migration.
- Provide rescue rules. Some holders may possess additional secret information that a quantum attacker cannot recover merely by deriving an exposed key.
For example, a holder whose key was derived through BIP-32 may be able to prove knowledge of a parent key in zero knowledge. The article notes that BIP-361 discusses rescue mechanisms and that a prototype prover had been implemented. Specific rescue rules might also be deferred to a later fork.
But millions of bitcoins with exposed public keys predate BIP-32. Wallets believed to belong to Satoshi Nakamoto are the most prominent example: the source estimates approximately 1.1 million BTC, valued at over $75 billion at the time of publication. Those ownership and valuation statements should not be read as independently verified holdings or current prices.
PACTs target the gap left when a holder has no suitable parent-key secret or other deterministic derivation history.
The mechanism: prove that control existed before a cutoff
Knowing an old private key after quantum attacks become practical would not establish rightful ownership: an attacker might know it too. A PACT instead aims to demonstrate that the claimant could produce a valid address-control proof before a designated cutoff.
The source illustrates this with a hypothetical timeline: a holder prepares evidence in 2026, Bitcoin sunsets ECDSA-key spending in an emergency soft fork in 2029, CRQCs arrive in 2030, and the holder seeks to spend in 2040. These dates are a thought experiment, not predictions or announced milestones.
Bitcoin supplies the timestamping foundation. OpenTimestamps aggregates hashes into Merkle trees and anchors them through Bitcoin transactions using OP_RETURN outputs. A holder can submit an opaque commitment rather than expose an address or signature.
Stage 1: create and retain a private commitment
In the illustrative design, the holder generates a 256-bit secret salt—32 random bytes—and uses BIP-322 full message signing to demonstrate control of the vulnerable output’s scriptPubKey, the script defining its spending conditions.
The signed message commits to:
- The PACT purpose and version.
- The Bitcoin network, illustrated as
bitcoin-mainnet. - The vulnerable output’s
scriptPubKey. - The secret salt.
The commitment is constructed as:
commitment = SHA256("PACT/v1 commitment" || salt || SHA256(control_proof))
Here, control_proof is the BIP-322 full message proof. The holder timestamps the commitment through OpenTimestamps and securely retains the salt, control proof and OpenTimestamps proof file.
The holder does not need to broadcast a Bitcoin transaction or pay an onchain commitment fee. OpenTimestamps is free to use and batches commitments into shared Bitcoin transactions; the process is therefore not entirely without an onchain anchor, even though the holder’s own action is offchain.
Only the opaque commitment is submitted. It does not reveal the salt, proof, public key, address or associated coins. Network metadata remains a separate privacy concern when contacting timestamping services.
Stage 2: prove eligibility for a rescue spend
If Bitcoin later adopted both a sunset and compatible PACT rescue rules, a claimant could supply a post-quantum-secure proof, such as a STARK, establishing that:
- They know the secret salt and BIP-322 control proof underlying the commitment.
- That proof is valid for the frozen output’s
scriptPubKeyand the specified PACT message. - The commitment was timestamped before the accepted cutoff, set before CRQCs were believed capable of deriving exposed private keys.
- The rescue proof authorizes the specific rescue transaction, preventing someone from copying it to redirect the coins.
The salt and control proof would remain hidden. The rules could also require only proof that the commitment was early enough, rather than disclosure of its precise timestamp.
The difficult part is consensus verification
Creating a commitment uses comparatively established components. Accepting it as authority to spend frozen bitcoin is a substantially larger engineering and consensus problem.
The eventual proof would need to establish an unbroken anchor chain: from the hidden salt and control proof to the commitment; through the OpenTimestamps hash operations to a calendar Merkle root; into a Bitcoin transaction’s OP_RETURN output; through a transaction Merkle proof into a block; and finally to a block recognized under the rescue rules as part of the active Bitcoin chain before the cutoff.
The article leaves open exactly how transaction-context verification would anchor this evidence to chain history, suggesting a recent block hash as a likely component. It explicitly acknowledges that STARK verification for these spends would require substantial new Bitcoin protocol infrastructure.
PACTs therefore defer difficult decisions rather than eliminate them. A standardized commitment format could let holders prepare before the community decides whether to sunset vulnerable spending, but a future consensus change would still determine whether those preparations have any spending authority.
Security assumptions and unresolved limits
There is no adoption guarantee. Bitcoin might never sunset quantum-vulnerable keys, or it might choose a different rescue mechanism. The source cautions holders against relying solely on PACTs before compatible rescue rules are adopted.
Preparation still involves key use and record retention. Producing a BIP-322 proof entails some signing risk. Although the proof and salt are not shared with OpenTimestamps, the holder must protect them and the timestamp proof file as recovery material.
Coverage is not universal. The proposal is expected to work for many single-key wallets, but multisignature arrangements, complex scripts, custodial wallets and hardware-wallet integration require careful standardization.
Message control and spending authority are not necessarily identical. The design assumes that producing a valid BIP-322 proof for the specified message corresponds to control of the coin. The source notes BIP-322’s qualification that the ability to sign messages from an address does not necessarily equal the ability to sign transactions from it.
Timestamp policy remains consequential. The rescue rules must define an accepted cutoff and recognize qualifying chain history. A timestamp created too late would not distinguish an original holder from a quantum attacker.
Assessment
PACTs offer a way to preserve evidence without immediately revealing that a dormant holder is active. Their proposed benefit is not quantum-proofing existing keys, but giving a future protocol a basis for distinguishing earlier control from later key recovery.
That makes them a potential preparation mechanism, not a completed security upgrade. The source identifies Jeremy Rubin’s similar design on Delving Bitcoin as prior work and presents its own construction as an invitation for expert and community input, rather than a formal proposal.
The unresolved question is whether Bitcoin could agree on and implement rescue rules that validate this evidence securely. Until then, a PACT would preserve a possible future claim—not guarantee access after a sunset.