Recently, Coinbase’s Independent Advisory Board on Quantum Computing and Blockchain published its first position paper on post-quantum migration strategies for blockchain systems.
The board includes Dan Boneh, Justin Drake, Yehuda Lindell, Scott Aaronson, Sreeram Kannan, and Dahlia Malkhi.
The paper covers consensus-layer migration, execution-layer migration, and chain-by-chain approaches across Bitcoin, Ethereum, Solana, Algorand, Sui, and Aptos.
In Section 4.3, the report evaluates four strategies for migrating execution-layer signatures to post-quantum security. The first strategy, “Generate private keys as hash outputs” — includes a single deployed example: Soundness.
Source paper:
Quantum Computing and Blockchain Position Paper (PDF)
This is the only deployed product referenced anywhere in that section.
For the past eight months, we have been building around this exact direction. This article explains what the report says, how our system fits into it, and what comes next.
What Strategy 1 Actually Means
The construction begins with a simple observation.
Most blockchain wallets today are derived from a seed:
BIP-39 for ECDSA ecosystems like Bitcoin and Ethereum
RFC 8032-style derivations for EdDSA ecosystems like Solana, Sui, Stellar, and Canton
The seed is hashed — typically using SHA-512 or PBKDF2 — to derive the signing scalar. The public key is then generated by multiplying that scalar with the curve generator.
A cryptographically relevant quantum computer running Shor’s algorithm can recover the signing scalar from the public key.
What it cannot do is invert the hash function and recover the original seed.
That means the seed remains a post-quantum-secure witness even after elliptic-curve signatures become vulnerable.
A zero-knowledge proof of knowledge of the seed allows a user to prove wallet ownership in a way that survives the quantum transition:
No address migration
No asset transfer
No chain hard fork
No account replacement
This is the construction formalized in our Financial Cryptography 2026 paper.
Related walkthrough:
Post-Quantum Readiness for Blockchain Today
The Property Scorecard
The report evaluates each migration strategy against four properties:
P1 — Does not weaken current security
P2 — Provides post-quantum security
P3 — Adds no significant cost today
P4 — Requires minimal blockchain changes
Strategy 1 is the only approach that receives a “YES” across all four categories.
The board’s primary recommendation is “move to 1-of-2,” a hybrid transition approach that scores positively on security and deployment practicality for many chains.
That recommendation makes sense for ecosystems willing to introduce hybrid signature models during migration.
But Strategy 1 occupies a different category entirely.
It is the only approach that:
Preserves existing addresses
Protects dormant accounts
Avoids forced migration
Requires no immediate chain coordination
The Main Critique: Performance
The report’s main criticism of Strategy 1 is performance:
“Such signatures will likely be very expensive, and so this would not be a good long-term solution in a post-quantum world.”
That concern is valid.
It is also the exact problem we have been working on for the last eight months.
Our FC 2026 implementation used Ligetron, a WebAssembly-accelerated proving system.
Results from that pipeline:
Proof size: 5.4 MB
Client-side proving time: ~6.2 seconds on an M4 MacBook Pro
Fully browser-based proving
No seed exposure outside the device
The codebase is open source:
While workable for client-side generation, 5.4 MB proofs were too heavy for scalable verification infrastructure.
So we redesigned the proving layer.
Moving from Ligetron to WHIR
Migrating to a WHIR-based proving system reduces proof sizes from megabytes to roughly 50 KB while also bringing proving and verification into sub-second territory.
WHIR belongs to the FRI/STIR family of hash-based polynomial commitments:
No trusted setup
Unconditional post-quantum security
Same client-side security model
Roughly two orders of magnitude smaller proofs
Achieving this reduction required substantial circuit redesign work:
SHA-512 preimage relations
Bit decomposition layers
Curve25519 arithmetic
Constraint optimization for recursive proving efficiency
None of this came for free.
All of it was necessary to make Strategy 1 operationally realistic at the verification layer.
Aggregation Changes the Economics
One part the report only briefly touches on is aggregation.
At the base layer, the system can operate per transaction:
User generates a PQ-NIZK proof
Chain verifies the proof alongside the classical signature
Existing account model remains untouched
This provides immediate post-quantum security without changing wallet infrastructure, but it introduces recurring proving and verification overhead.
Aggregation changes the picture.
Multiple proofs can be compressed into a single batch proof so validators verify one proof instead of many.
For institutional custody systems and threshold architectures, this is the difference between something theoretically interesting and something deployable.
It also creates an unusual side effect:
The construction behaves like a cryptographic form of account abstraction without requiring smart-contract wallets, delegation systems, or execution-layer rewrites.
The chain sees a single proof.
Users keep their existing addresses.
The More Natural Deployment Model: Account-Level Migration
The long-term deployment path is not per-transaction proving.
It is account-level binding.
Instead of generating a proof for every transaction, a user generates a single proof binding a newly generated post-quantum key to their existing on-chain identity.
That post-quantum key could be:
Dilithium
Falcon
Future NIST-standardized systems
The proof is verified once.
After that:
Transactions are authenticated directly under the new PQ key
No further proofs are needed
No recurring proving costs remain
This distinction matters.
Transaction-level proofs provide immediate protection with zero migration assumptions.
Account-level binding removes ongoing cost entirely after a one-time enrollment step.
Even in a future where chains natively support post-quantum signatures, existing accounts still need a secure way to link old identities to new keys.
This construction provides that bridge while preserving dormant accounts whose owners may not be online during the migration window.
What Works Today
Our enrollment platform, PQ-Me, already supports five wallets across five networks.
Users can:
Connect a wallet
Generate the proof locally in the browser through WebAssembly
Download a PQ certificate
The seed never leaves the device.
The entire proving flow is client-side.
Interactive explainer:
PQ Stack Interactive Demo
The explainer visualizes:
Seed derivation
Proof generation
On-chain verification
Standard EdDSA signing flow
PQ-protected execution flow
side by side.
What Comes Next
Three parallel directions are currently active.
Bitcoin Support
The construction extends to ECDSA through hardened BIP-32 derivation paths.
The circuit is substantially heavier:
PBKDF2
2048 HMAC-SHA512 iterations
Roughly 100× the proving cost of the EdDSA version
Despite this, proof size targets remain comparable.
Work is ongoing.
Native Chain Support
Allowing validators to accept Mode 2 signatures alongside classical signatures is fundamentally a software-layer upgrade rather than a consensus rewrite.
We are actively discussing deployment paths with multiple chain teams.
At the same time, we are continuing to reduce costs through:
Better proving systems
Aggregation
Verification optimizations
Native PQ verification primitives
Once these primitives exist at the EVM layer and equivalent execution environments, the economics shift significantly.
Threshold and HSM Extensions
The MPC extension is currently in development:
2-of-3 signing
Seed-based DKG
Aggregatable proofs
Rogue witness mitigation
In parallel, the HSM-oriented construction:
Hidden public keys
ZK signature proofs
Custody-compatible flows
has already been integrated with regulated custody requirements in mind.
Closing
Eight months ago, the core bet was simple:
The seed is the correct post-quantum anchor
Client-side proving can make the model practical
The Coinbase Independent Advisory Board has now cited our deployment as the only implemented example of the strategy that scores positively across every property in their evaluation framework.
The board recommends hybrid “1-of-2” migration as the primary transition path, and that reasoning is sound for many ecosystems.
But for users who want to:
Preserve existing addresses
Protect dormant accounts
Avoid forced migration
Maintain compatibility across chains
Strategy 1 remains the only approach that achieves all four simultaneously.
And today, we are the only team that has deployed it.
The work to make it cheaper, faster, and easier to integrate continues.
