A quantum computer doesn't print money. It reads keys.
The usual version of this story has a machine conjuring coins out of nothing. That is not the threat, and getting it wrong hides the part that should actually worry you: a transparent chain has been publishing the exact material a future machine needs, in the clear, since the day it launched.
Public keys stop being public knowledge
Shor's algorithm recovers a private key from a public key on any elliptic curve in use today. Not by guessing. By solving the problem the curve's security rests on, in polynomial time.
Hashes get a haircut, and survive it
Grover's algorithm square-roots the work of a brute-force search, so a 256-bit hash behaves like a 128-bit one. That is an inconvenience. SHA-256 and BLAKE2 are not where this goes wrong.
Nothing here mints a coin
Consensus rules still check supply. What an attacker gets is the ability to sign as somebody else — to move coins that already exist, from keys that were never theirs.
The archive is already downloaded
This is the part that makes the timeline shorter than it looks. The attack does not need the machine and the target to exist at the same moment.
Every spend is a disclosure
- To spend from an address you publish a signature, and that signature publishes the public key. Every address that has ever sent anything has already done this.
- Those keys sit in a public archive that anyone can download today and keep forever. Whoever wants them has them.
- When a machine capable of running Shor at that scale exists, the work of finding targets is already done. The only question left is which balances are worth the compute.
- Moving to a fresh address does not retroactively help: the old key is still published, and the funds still have to be moved with it.
There is nothing in the archive to point at
- A shielded spend proves you are entitled to spend without publishing the key that entitles you. No public key goes on chain — not encrypted, not hashed, not there.
- Amounts and recipients are ciphertext, so an attacker cannot rank targets by balance. There is no rich list to work down.
- Address reuse is not a leak. Two payments to the same shielded address produce two unlinkable note commitments.
- The harvest-now strategy has nothing to harvest that identifies a holder, because holders are not identified.
Shielded is not post-quantum, and anyone telling you otherwise is selling something
Zcash's shielded pools rest on elliptic curves like everything else. Orchard's proofs are Halo 2 over the Pallas and Vesta curves; Sapling's are Groth16 over BLS12-381. A machine large enough to run Shor against those curves could forge a proof, and forging a proof is the one thing that really would let somebody create value out of nothing inside a pool. That is a protocol-level migration and it is not finished anywhere.
There is a second problem that is easier to overlook and harder to undo. Note ciphertexts — the encrypted amounts and memos — are archived publicly too, and the key agreement that protects them is also curve-based. An adversary recording the chain today could, later, decrypt what it recorded. Shielded privacy is forward-looking, not retroactive. The question is not only what an attacker can steal in the future; it is what they can read about the past.
What shielding genuinely changes is the targeting problem, and it changes it now, with no migration required. A transparent chain hands an attacker a sorted list of keys and balances. A shielded pool hands them an undifferentiated set of commitments. That is worth a great deal, and it is not the same thing as being safe.
What Ztek signs with, today
We cannot migrate a chain's proving system from a website. We can decide what an agent's authorizations are signed with, and that decision is ours to make.
Generate a keypair
No key yet. Generating one runs the real FIPS 204 keygen on 32 bytes from the browser CSPRNG.
The thing being authorized
Edit anything — change total by one digit — then verify again.
Sign it
Generate a key first.
Verify it
Sign something first.
| Ed25519 | ML-DSA-65 | |
|---|---|---|
| public key | 32 B | 1,952 B |
| secret key | 64 B | 4,032 B |
| signature | 64 B | 3,309 B |
| classical | ≈128-bit | ≈192-bit |
| vs Shor | broken | not applicable |
ML-DSA-65 is NIST level 3 and its hardness comes from lattice problems — module learning-with-errors and module short-integer-solution — which Shor's algorithm has nothing to say about.
A 3,309-byte signature does not fit in a 512-byte shielded memo, and it should not want to — block space is the most expensive storage in existence.
So it does not go there. The memo carries a 32-byte digest of the authorization. The signature itself travels with the job, off chain, where a counterparty verifies it before doing any work. The chain stores the commitment; the parties keep the proof.
wire ← auth ‖ ML-DSA-65 sig · 3,529 B
chain stores the first. parties keep the second.
Still on the list
Hybrid key agreement
designed, not shippedJob payloads between agents are encrypted with X25519 today. The plan is X25519 + ML-KEM-768 in a hybrid, so recording the traffic now does not pay off later.
Rotation that means something
partialAgents rotate authorization keys on a schedule, but a rotation only helps if old signatures expire. Authorization expiry is in the payload; enforcement is not built.
The proving system
upstreamNot ours to fix. Zcash's shielded pools need a post-quantum proving system and that work happens upstream. We will follow it; we cannot lead it.