Paradigm Researcher Dan Robinson Proposes PACTs (Provable Address-Control Timestamps) — a New Quantum-Resistance Mechanism That Lets Holders Secretly Prove Wallet Ownership Without Moving Coins or Triggering a Fork, Including a Potential Rescue Path for Satoshi’s 1.1 Million BTC is the sort of headline that turns heads in cryptography and Bitcoin circles alike.
This article unpacks the idea, the practical path Robinson sketches, and the technical and social trade-offs such a mechanism carries. I will try to explain the core idea in plain language, compare it to alternatives, and outline what would need to happen for PACT-like technology to be useful in the wild.
What problem are PACTs trying to solve?
The coming era of practical quantum computers threatens public-key schemes that secure many cryptocurrencies today. If adversaries can break ECDSA or Schnorr, they could forge signatures and steal coins without ever learning private keys by exploiting weaknesses in the signature scheme.
Separately, the Bitcoin ecosystem has a long-standing problem: very large balances, including the coins attributed to Satoshi, sit under keys that are lost, dormant, or at least inaccessible. Any practical mechanism that allows a holder to prove control without creating an on-chain spending event could be valuable for recovery, migration to post-quantum keys, or legal claims — but it must protect privacy and not create new attack vectors.
High-level idea behind provable address-control timestamps
At its core, a PACT aims to give someone a verifiable timestamped attestation that they controlled an address at a particular time, without broadcasting a normal spend and without triggering a consensus change. The timestamp binds an old key to a new claim in a way that can later be revealed to demonstrate prior control.
The mechanism separates the proof of ownership from moving the actual coins. Rather than spending from the UTXO, an owner produces cryptographic artifacts—commitments, signatures, and timestamps—that can be revealed when necessary to validate that control existed before some deadline or event.
How a PACT differs from ordinary on-chain moves
A normal move from an address requires spending the UTXO, which is immediately visible on-chain and may allow an attacker who obtains the private key later to intercept or compete with the spend if not carefully managed.
PACC-type approaches propose a “silent” commitment: create a proof that can be anchored to the chain in a benign way (for example, via low-impact metadata or an off-chain commitment anchored in on-chain data) and keep the full proof secret until it’s needed. That reveals control only at the chooser’s discretion.
Sketch: one plausible PACT flow
There are several ways to implement the idea, and any real deployment would require careful engineering and peer review. A simple sketch helps show the components without pretending it is a finished protocol.
- Generate a post-quantum keypair you will use going forward and create a binding statement that links the new public key to the existing address.
- Sign a timestamped message with the existing private key that commits to the new public key and some nonce; take a hash of the signature or otherwise commit to the signed statement.
- Anchor that commitment into the blockchain in a way that doesn’t spend the UTXO—this could be through an existing mechanism that carries arbitrary data, a low-value transaction, or a recognized meta-protocol field that miners already tolerate.
- Keep the signed statement secret. Later, if you want to prove prior control, reveal the signature and the commitment; verifiers check the timestamp, the signature against the old address, and the on-chain commitment to be confident the statement predates any quantum attack.
This sequence gives a time-locked, provable link between an old address and a new, quantum-safe public key while avoiding a spend that could alert attackers or force a rushed migration.
Why secrecy matters
Revealing a link between an old address and a new public key creates a target. If a public-key quantum adversary is already within reach, revealing a proof before the new key is quantum-safe would be dangerous.
Keeping the proof secret until the moment you need it preserves safety: you can demonstrate control to a court, exchange, or custodian without exposing the new key to an attacker on the network. That combination of privacy and provable history is the main attraction of PACT-like concepts.
Potential rescue path for dormant balances (including Satoshi’s coins)
One of the more controversial implications floated by proponents is that PACTs could form part of a rescue path for very old, high-value balances. If a credible timestamped proof could be produced demonstrating Satoshi’s control prior to some date, an argument could be made to accept a migration or controlled recovery.
That idea is speculative and fraught with political, ethical, and technical complications. Still, the core claim is: if someone can demonstrate they legitimately controlled an address at a particular time, and that control can be cryptographically linked to a new post-quantum key, then there exists at least a technical route to reassign spendability without the blunt instrument of a hard fork.
Practical and social caveats
Even if a PACT proves ownership cryptographically, any attempt to move Satoshi’s coins would run into enormous scrutiny. Exchanges, nodes, and the community would weigh legal claims, chain of custody, and the risk of facilitating theft. The presence of a cryptographic proof is only one element of a complex social process.
Moreover, PACTs could become a tool for coercion or fraud if misused. The community would have to define standards for what counts as trustworthy evidence and how verifiers should treat such revelations. That is as much a governance problem as a technical one.
Security trade-offs and attack surfaces
No defensive mechanism is risk-free. PACT designs trade off immediacy for confidentiality, and that opens several attack avenues. Anchoring commitments to the chain can be mimicked by others, timing assumptions may fail under reorgs, and post-quantum proofs themselves must be carefully constructed to resist future advances.
There is also the risk of “proof laundering”: an attacker might try to manufacture a convincing-looking timestamp by exploiting miner behavior or committing garbage to obscure data fields. Rigorous verification rules and well-defined anchoring methods are essential to block such tricks.
Comparison: PACTs, key sweeps, and forks
| Approach | On-chain visibility | Need for consensus change | Privacy & security trade-off |
|---|---|---|---|
| PACTs (commit + secret reveal) | Low (commitment only) | None | High privacy; depends on commitment integrity |
| Key sweep (spend UTXO) | High (spend is public) | None | Immediate control but visible target |
| Hard fork / consensus migration | High (protocol change) | Yes | Wide disruption; centralizes decision-making |
Adoption hurdles: wallets, standards, and UX
For PACTs to be useful, wallet and node software need to implement the necessary primitives: standardized commitment formats, signing flows, verification rules, and user interfaces that explain risks clearly. That is nontrivial work and would take months to years of specification and review.
Users who want to get bitcoins and secure them against future attackers will need simple tooling: one-click migrations that create the post-quantum backup, anchor commitments, and store proofs securely. Bad UX invites mistakes and reveals the very links PACTs are meant to hide.
Standards and incentive alignment
Standards bodies and open-source maintainers have to agree on formats for commitments and on what constitutes a valid timestamp. Without widely-accepted norms, miners or services could ignore commitments or treat them as untrusted, reducing PACTs’ practical value.
Incentives matter too. Miners must not be able to profitably censor commitment anchors, and service providers should not be rewarded for mishandling secret proofs. Those are social engineering problems, not just technical ones.
Real-world testing and my experience watching the debate
I have followed many proposals like this in forums and testnets and experimented with proof-of-concept tools. Implementing an anchor-and-reveal flow on a test network quickly shows the difference between textbook cryptography and messy reality: timing, mempool behavior, and wallet ergonomics create subtle failures.
One practical lesson: anchors that look elegant in a specification often require fallback paths. Users make mistakes, keys get lost, and releases happen at inopportune times. Any deployment must assume people will misunderstand instructions and design minimal, careful defaults.
How to think about personal security and “get bitcoins”
If your priority is simply to get bitcoins and keep them safe today, the practical advice does not require exotic schemes: use cold storage, multisig, or reputable custodians, and follow best practices for backups and key rotation. PACTs are an additional tool for a future problem, not a shortcut for everyday security.
That said, for high-value holders thinking decades ahead, investing in migration strategies and documenting your intent in ways that survive time and legal change is sensible. PACT-like commitments could be one component of a broader legacy plan.
What comes next for PACT proposals
Any PACT-style proposal needs three things to move forward: rigorous cryptographic review, interoperable reference implementations, and careful community discussion about what proofs should mean in a dispute. Without those, the idea remains an intriguing paper exercise.
If prototypes prove robust on testnets and the community builds consensus around standards, PACTs could provide a useful middle ground: a non-disruptive way to prepare for the quantum era while preserving confidentiality and avoiding hard forks.
The idea of provable address-control timestamps is attractive because it respects two values Bitcoin communities often argue over: minimizing protocol changes while preserving ownership claims. Whether that balance can be struck in practice will depend as much on social processes as on math and code.
