Industrial Cryptography And Its Future
donuts-are-good, Blocknet Team
The tweet
This started with a tweet. Justin Drake (https://x.com/drakefjustin/status/2061793725299224676), posting in June 2026, walking through a Google Quantum AI result on Shor's algorithm against elliptic curves. The short version of his thread: Google found a roughly 10x improvement on the quantum attack and demonstrated it on secp256k1, the curve under Bitcoin and Ethereum. They withheld the circuit and proved its existence with a ZK proof instead of publishing it. Two months later a French researcher, André Schrottenloher, rederived the main optimization anyway and put it on arXiv. Drake then gave his own read on timing: 50% odds that a quantum computer breaks production cryptography by 2032, 10% by 2030. A startup called Oratomic claimed 10,000 physical qubits would be enough for secp256k1 on neutral-atom hardware.
We had the Schrottenloher paper already, sitting in a folder. arXiv:2606.02235. It is an unglamorous title: "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms", and it gives concrete numbers. For secp256k1, a space-optimized circuit uses 1,192 logical qubits and on the order of 2^21 Toffoli gates per point addition, with a full Shor run landing near 2^26 Toffoli gates. The circuit generalizes to any prime field. blocknet does not run on secp256k1, so the secp256k1 framing did not apply to us directly, but the generality did.
The first instinct, the one we had to talk ourselves out of, was the same one everybody has: the panic about big numbers. People look at a 256-bit prime and reason that a bigger or stranger prime buys safety. It does not. Shor's algorithm does not attack the size of a number. It attacks a structure, the hidden subgroup problem over abelian groups, and both factoring and discrete log are special cases of that one structure. The prime is the container the group lives in. Picking a weirder prime changes nothing about the group. So the real question was never "is our prime big enough." It was "does our security rest on a group that Shor dismantles." For blocknet, the answer was yes, everywhere we looked.
Taking inventory
We went through what blocknet actually runs. The list was not reassuring.
| What it does |
What we use |
What it rests on |
| Keys and signatures |
Ed25519 |
Curve25519 discrete log |
| Spend authorization |
Schnorr over Ristretto255 |
discrete log |
| Transaction privacy |
CLSAG ring signatures (ring size 16) |
discrete log |
| Hiding amounts |
Pedersen commitments |
discrete log |
| Range proofs |
Bulletproofs |
discrete log |
| Stealth addresses |
ECDH one-time keys |
discrete log |
| Double-spend tags |
key images, I = k·Hp(K) |
discrete log |
Every line rests on the same assumption. That is the property that makes Shor so brutal against a chain like ours: one algorithm against one structure takes down the whole column at once. There is no component that quietly survives while the others fall.
Then we looked at the work we were in the middle of, and it got worse. We have been building FCMP++, full-chain membership proofs with spend authorization and linkability, and the proving infrastructure under it is the Ran/Shaw curve cycle over the Curve25519 field. Ran and Shaw are a careful piece of engineering. The search behind them scanned 16.1 trillion discriminants and produced a cycle with 254-bit twist security on both sides. The reason that cycle exists at all is to make recursive proof composition over elliptic curves cheap, by letting each curve's scalar field match the other's base field so you avoid foreign-field arithmetic.
The catch is that recursive proof composition over elliptic curves is recursive proof composition over the exact group Shor eats. We were building our future on the same math that the tweet was warning us about. Ran/Shaw is good work and it keeps its value for the pre-quantum window, but a post-quantum spend path cannot sit on a curve cycle. That realization is what turned this from reading into a project.
The question we got wrong first
The obvious move is to go shopping for a post-quantum signature and drop it in where Ed25519 used to be. We spent some time there. The menu of standardized and near-standardized schemes looks like this:
| Scheme |
Signature |
Key |
Basis |
| SPHINCS+ / SLH-DSA |
7–49 KB |
32–64 B |
hashes only |
| ML-DSA / Dilithium |
2.4–4.6 KB |
1.3–2.5 KB |
lattices (Module-LWE) |
| XMSS / LMS |
~2.5 KB |
small |
hashes, but stateful |
| Falcon |
~0.7 KB |
~0.9 KB |
NTRU lattices |
None of them fit, and the reason they do not fit told us we were asking the wrong question. blocknet does not hand the network a signature. It hands the network a zero-knowledge proof that some output in the set is ours and that we are allowed to spend it, with a tag that stops us from spending it twice. Swapping Schnorr for Dilithium authorizes a key, and then we still have to account for ring membership, amount hiding, and range proofs separately. The signature was never the unit of the system. The proof was.
Once we stated it that way, the question rewrote itself. The thing that had to survive a quantum adversary was the proof system, since the spend authorization already lived inside the proof. A drop-in signature solved a problem we did not have.
What actually survives
Proof systems do not all break the same way, and most of them do not break in the proof system itself. They break in the assumption underneath.
| Proof system |
Rests on |
Quantum |
| Groth16 |
pairings (BN254, BLS12-381) |
dead |
| PLONK / KZG |
curve discrete log |
dead |
| Bulletproofs / IPA |
curve discrete log |
dead |
| Curve-cycle SNARKs (Ran/Shaw) |
curve discrete log |
dead |
| STARKs (FRI) |
hash collision resistance |
survives |
| Lattice SNARKs |
LWE / SIS |
believed safe, immature |
The dividing line is the assumption. Anything resting on a group with discrete log structure dies with the rest of the column. Hash-based proof systems rest on a hash function being hard to invert and hard to collide, and quantum does not have a Shor-style attack on that. Grover's algorithm gives a square-root speedup on brute-force search, which you cancel by doubling the output. A hash-based proof at 256-bit internal width gives 128-bit security against a quantum attacker.
So the fund-critical path goes hash-based. The spend proof is a STARK. No elliptic curve operation appears anywhere in the circuit. This is the same family of tools Drake's Ethereum work is built on, and we want to be plain about that: the technique is general, it predates anyone's branding, and using a hash-based proof system does not make this an Ethereum design. We are not importing leanVM or its stack. We are using the one class of proof system that is left standing.
One proof instead of many
The current transaction carries a CLSAG signature per input and a Bulletproof per output, with the balance enforced publicly through Pedersen commitment addition. A 2-input, 2-output transaction comes out around 3.9 KB: two RingCT CLSAG signatures at 1,120 bytes each, two non-aggregated Bulletproofs near 672 bytes each, plus commitments and ephemeral keys.
Going hash-based let us collapse all of that into one proof per transaction. The statement the proof carries, for a transaction with m inputs and n outputs:
- each input's one-time public key sits in the UTXO tree (a Merkle path to the root)
- each input's key image is derived correctly from the spending key
- each output amount is in range,
0 ≤ v < 2^64
- the amounts balance,
Σ inputs = Σ outputs + fee
All of it, every input and output, in a single proof. That consolidation is available precisely because there are no curves left in the circuit. There is no cross-field arithmetic to engineer around, so there is no need for a curve cycle. The membership statement becomes a Merkle path, the key becomes K = H(k), and the key image becomes I = H("image" ‖ k), deterministic so double-spends are caught and unlinkable so privacy holds, all inside the proof as a few more hash evaluations.
For a 2-in-2-out transaction at tree depth 30, the circuit is small: roughly 64 internal-tree hashes, 5 external hashes, 128 bit-decomposition constraints for the ranges, and one balance check.
Choosing the hash that goes in the circuit
The hash inside the Merkle tree is the expensive part, because the proof has to verify each tree hash as an arithmetic circuit. The algebraic cost of that hash sets the proof's size and the prover's time. We needed a hash that is cheap to express as field arithmetic and has held up under attack. There is a whole family designed for exactly this, and a good chunk of it is in trouble.
We read the recent cryptanalysis rather than the marketing.
Griffin (Crypto 2023) is out. The FreeLunch attack recovered CICO solutions for 7 of its 10 rounds in under four hours on one core, and resultant-based follow-ups at Crypto and Asiacrypt 2024 narrowed the margins further. Full-round instances fall in the k=1 case. That is the shape of a primitive on its way to being broken, and we are not putting funds behind it.
Anemoi (Crypto 2023) is out for a quieter reason. A EUROCRYPT 2025 analysis showed that 256-bit security needs at least 41 rounds where the designers specified 37, and that figure carries no security margin of its own. When the people who built the thing undercounted the rounds, more attacks usually follow.
Poseidon2 stays in. It is the most deployed and the most attacked of the family. The Ethereum Foundation has had a $130,000 bounty open on it across 2024–2026, and the live attacks — Gröbner basis work exploiting subspace trails, Graeffe-transform attacks on the challenge instances — have broken reduced-round targets without breaking full-round production parameters. A proposed tweak closes the subspace-trail issue. StarkWare's Stwo prover does over 600,000 Poseidon2 hashes per second on an M3 Pro. Years of paid effort to break it, no full-round break, is the strongest evidence available that it holds.
Rescue-Prime is the fallback. Older, more conservative, a completed bounty program, and slower. If Poseidon2 ever falls at full rounds, the tree hash migrates to Rescue-Prime through a fork, and the rest of the design is unaffected.
Outside the circuit, for key derivation and key images and anything users actually touch, we kept SHA3-512. It is the most analyzed option we have, it is already in blocknet, and quantum does not get near it: even truncated to 256 bits for storage, preimage resistance is 2^128 against Grover, which is the floor the rest of the system sits at anyway. We use SHA3-512 rather than SHA3-256 for domain-separation headroom and truncate the deployed outputs.
The stealth address wall
This is where we lost an argument with mathematics. We wanted the whole system hash-only, including the way a sender pays a recipient who is offline. We could not have it.
A stealth address lets a sender create an output that only the recipient can recognize and spend, with no prior contact. That capability is equivalent to public-key encryption. You can build an encryption scheme out of a stealth address scheme by having the sender choose which of two addresses to pay and letting the recipient read the choice. Public-key encryption cannot be built from hash functions alone; that is a known impossibility. So a stealth address that works while the recipient is offline has to carry some asymmetric cryptography. There was no hash-only version to find.
We considered dropping stealth addresses and requiring an interaction to set up each payment, the way Grin works. That fails the basic test of a currency: someone has to be able to pay you while you are asleep. So we accepted asymmetric crypto for detection, and went looking for the post-quantum option that hurt the least.
| Option |
Public key |
Per-tx ciphertext |
Basis |
Age of analysis |
| Classic McEliece (348864) |
261 KB |
96 B |
code decoding |
40+ years |
| Kyber-512 (ML-KEM) |
800 B |
768 B |
Module-LWE |
~15 years |
| NTRU-HPS-509 |
699 B |
699 B |
NTRU lattice |
~25 years |
McEliece is the conservative choice by a wide margin, and its shape matched our original wish for big keys and small per-transaction data: 96-byte ciphertexts. The problem is the 261 KB key. You cannot put that in a QR code or paste it in a chat. It needs hosting, which means either an on-chain registry or off-chain infrastructure.
We tried the on-chain registry idea and watched it fall apart for a privacy chain. A public list of every recipient's key is a public list of every participant. Registration needs a fee, and a fee needs coins, and getting coins needs someone to pay you, which needs you registered first. Registration timing and network metadata become deanonymization handles. We even sketched a service that floods the registry with decoy keys to spoil correlation, and it does not fix anything; it just makes the participant list longer. The registry was the wrong building block.
Kyber-512 avoids all of it. The 800-byte key is shareable as a QR code or a URI. The 768-byte ciphertext per output is real overhead, but the proof already sets the size of a transaction, so 768 bytes is noise against it. Choosing McEliece would shave 672 bytes off each output and cost us a key-distribution problem; that trade was not worth it once the proof, not the ciphertext, set the floor.
For distribution we reused something we already run. blocknet.id is our name service, the way sns.id works for Solana. We pointed it at Kyber keys: a name resolves to an 800-byte public key, the service answers single lookups rather than handing out the whole list, and if it goes down people fall back to sharing the raw key directly. It is a convenience layer with no power over funds. The worst it can do is go offline, which the raw-key fallback covers, or serve a wrong key, which key-pinning or a spend-key-signed registration covers.
One thing we gave up here. The current design separates a view key from a spend key, so you can hand someone read-only scanning access. In the new design the Kyber private key does the scanning and the hash-based key does the spending, both from one seed, and there is no clean way to delegate scan-only access without also handing over spend power. Watch-only wallets and auditor access have to come from somewhere else, an encrypted transaction export or a selective disclosure proof. We took that loss on purpose rather than carry a second Kyber keypair or a re-encryption scheme.
We stopped having signatures
The fear we started with was huge signatures. The way out was to stop having them. The new transaction carries no ring signature and no per-output range proof. It carries one proof. That single object stands in for all sixteen ring members on every input, the range proof on every output, and the balance check, and it proves the lot against the whole chain instead of a ring of sixteen decoys.
A single transaction proof is a hash-based STARK, and a hash-based STARK is not small in absolute terms. A FRI proof leans on Merkle authentication paths across many query rounds, and that overhead sets a floor in the tens of kilobytes even for a circuit as small as ours. Our working estimate for the spend circuit sits in that range, with the exact figure depending on the field, the FRI parameters, and how hard we recurse. That is the one number left to settle on a real prover, and we will publish it measured rather than estimated.
What stops that number from compounding is the property that made us pick this family of proofs to begin with. Hash-based proofs recurse. A block folds the proofs of all its transactions into one proof that says every transaction in the block verified, so a node syncing the chain downloads one proof per block instead of one per transaction. The per-transaction proof is what a sender broadcasts to the mempool, where a relaying node checks it on its own before it is mined; the folded block proof is what the chain stores and what a fresh node replays. This is the lever the early thinking already pointed at, when we said the way to pay down the cost of large post-quantum proofs is aggregation. It is the same lever, run with hash-based recursion in place of a curve cycle, and it lands directly on the part of blocknet that hurts, which is sync time under a 2 GB proof of work. The full proof is paid once, at relay. The chain and everyone syncing it pay the folded cost.
The keys stay small through all of this. A spending key is a 256-bit secret and its public key is a 32-byte hash. The one larger object a user holds is the 800-byte Kyber address, published once to a name. There is no 261 KB key to host and no fat per-signature blob to repeat, because there is no signature left to repeat.
Where this leaves us
The security comes down to one separation. The only non-hash assumption anywhere is Kyber, and Kyber guards privacy, not money. If Module-LWE falls to some future algorithm, an attacker learns which outputs were addressed to which key. They still cannot spend those outputs, because spending needs the hash-based key, and that rests on preimage resistance. The conservative assumption protects the thing that matters most, and the younger one only ever costs privacy.
The migration is still an open call between a hard fork that drags every existing Pedersen-committed output into a new Poseidon2 tree, and a clean relaunch. The quantum threat invalidates every existing key regardless, so a relaunch is on the table in a way it would not normally be; holders have to rotate keys either way.
Industrial cryptography
Step back from blocknet and the picture is uniform. The cryptography that secures this whole industry sits on elliptic curves, and the chains holding the most money sit on the most exposed version of it.
Bitcoin is secp256k1, the exact curve the Google and Schrottenloher circuits were demonstrated on. Every coin held at a reused address, and every coin whose public key has ever touched the chain, is a static target the day a machine can run Shor. Ethereum is no better placed: BLS signatures at the consensus layer, KZG commitments at the data layer, and ECDSA at the execution layer are all pairing or discrete-log constructions, all broken by the same algorithm. Ethereum at least has a declared plan, hash-based and aimed at 2029, which is more than most of the field can say.
Our own corner, the privacy chains, has been doing careful work that the quantum results just retired. Monero's forward path for full-chain membership proofs runs on the Helios/Selene curve cycle. Ran/Shaw was built to do that job better, and it does: 254-bit twist security on both curves against Helios/Selene's hundred-odd bits before its script bug was corrected and a little over two hundred after, chosen by a transparent search instead of landed on by accident. None of that edge survives Shor. A curve cycle is two elliptic curves, and Shor does not care which of two cycles is the more careful piece of engineering. The contest between Helios/Selene and Ran/Shaw was a contest over which broken primitive broke more gracefully, and the quantum posts settled it by breaking both at once.
That is the whole reason this design leaves curves behind on the spend path. The best curve-cycle work in the privacy space, ours included, lands on the wrong side of the line Shor draws. Hash-based proofs are the only entry in the list still standing once that line is drawn, and the price of using them is bandwidth, which is a problem we know how to chip at. The price of not using them is that the chain stops being secure the morning qday arrives.
blocknet is small enough to move before that morning. The large chains are not, and the value they carry makes a quiet migration impossible: you cannot rotate tens of millions of exposed keys without the rotation becoming the event. We would rather make the move now, while the amount at stake is survivable and the design can be argued over in the open, than inherit the position Bitcoin is walking into. The formal construction, with the circuit, the key derivation, the transaction format, and the security analysis, is written up in the protocol specification. The one number we still owe is the measured proof size, and it will land when the prover is real.
Sources
- A. Schrottenloher, "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms," arXiv:2606.02235, June 2026.
- R. Babbush et al., "Securing elliptic curve cryptocurrencies against quantum vulnerabilities," arXiv:2603.28846, 2026.
- J. Drake, thread on the Google Quantum AI result and qday timing, June 2026.
- B. Lehmann, @donuts-are-good, "Ran and Shaw: A High-Security Curve Cycle over the Curve25519 Field," 2026. github.com/gibme-c/ranshaw
- L. Grassi, R. Koschatko, C. Rechberger, "Poseidon and Neptune: Gröbner Basis Cryptanalysis Exploiting Subspace Trails," IACR ToSC 2025(2).
- "Breaking Poseidon Challenges with Graeffe Transforms," IACR ePrint 2025/950.
- "The Algebraic FreeLunch: Gröbner Basis Attacks Against Arithmetization- Oriented Primitives," Crypto 2024.
- L. Campa, A. Roy, "Gröbner Basis Cryptanalysis of Anemoi," EUROCRYPT 2025, IACR ePrint 2025/814.
- "Post-Quantum Stealth Address Protocols," arXiv:2501.13733, January 2025.
- NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard," FIPS 203, August 2024.
Industrial Cryptography And Its Future
donuts-are-good, Blocknet Team
The tweet
This started with a tweet. Justin Drake (https://x.com/drakefjustin/status/2061793725299224676), posting in June 2026, walking through a Google Quantum AI result on Shor's algorithm against elliptic curves. The short version of his thread: Google found a roughly 10x improvement on the quantum attack and demonstrated it on secp256k1, the curve under Bitcoin and Ethereum. They withheld the circuit and proved its existence with a ZK proof instead of publishing it. Two months later a French researcher, André Schrottenloher, rederived the main optimization anyway and put it on arXiv. Drake then gave his own read on timing: 50% odds that a quantum computer breaks production cryptography by 2032, 10% by 2030. A startup called Oratomic claimed 10,000 physical qubits would be enough for secp256k1 on neutral-atom hardware.
We had the Schrottenloher paper already, sitting in a folder. arXiv:2606.02235. It is an unglamorous title: "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms", and it gives concrete numbers. For secp256k1, a space-optimized circuit uses 1,192 logical qubits and on the order of 2^21 Toffoli gates per point addition, with a full Shor run landing near 2^26 Toffoli gates. The circuit generalizes to any prime field. blocknet does not run on secp256k1, so the secp256k1 framing did not apply to us directly, but the generality did.
The first instinct, the one we had to talk ourselves out of, was the same one everybody has: the panic about big numbers. People look at a 256-bit prime and reason that a bigger or stranger prime buys safety. It does not. Shor's algorithm does not attack the size of a number. It attacks a structure, the hidden subgroup problem over abelian groups, and both factoring and discrete log are special cases of that one structure. The prime is the container the group lives in. Picking a weirder prime changes nothing about the group. So the real question was never "is our prime big enough." It was "does our security rest on a group that Shor dismantles." For blocknet, the answer was yes, everywhere we looked.
Taking inventory
We went through what blocknet actually runs. The list was not reassuring.
I = k·Hp(K)Every line rests on the same assumption. That is the property that makes Shor so brutal against a chain like ours: one algorithm against one structure takes down the whole column at once. There is no component that quietly survives while the others fall.
Then we looked at the work we were in the middle of, and it got worse. We have been building FCMP++, full-chain membership proofs with spend authorization and linkability, and the proving infrastructure under it is the Ran/Shaw curve cycle over the Curve25519 field. Ran and Shaw are a careful piece of engineering. The search behind them scanned 16.1 trillion discriminants and produced a cycle with 254-bit twist security on both sides. The reason that cycle exists at all is to make recursive proof composition over elliptic curves cheap, by letting each curve's scalar field match the other's base field so you avoid foreign-field arithmetic.
The catch is that recursive proof composition over elliptic curves is recursive proof composition over the exact group Shor eats. We were building our future on the same math that the tweet was warning us about. Ran/Shaw is good work and it keeps its value for the pre-quantum window, but a post-quantum spend path cannot sit on a curve cycle. That realization is what turned this from reading into a project.
The question we got wrong first
The obvious move is to go shopping for a post-quantum signature and drop it in where Ed25519 used to be. We spent some time there. The menu of standardized and near-standardized schemes looks like this:
None of them fit, and the reason they do not fit told us we were asking the wrong question. blocknet does not hand the network a signature. It hands the network a zero-knowledge proof that some output in the set is ours and that we are allowed to spend it, with a tag that stops us from spending it twice. Swapping Schnorr for Dilithium authorizes a key, and then we still have to account for ring membership, amount hiding, and range proofs separately. The signature was never the unit of the system. The proof was.
Once we stated it that way, the question rewrote itself. The thing that had to survive a quantum adversary was the proof system, since the spend authorization already lived inside the proof. A drop-in signature solved a problem we did not have.
What actually survives
Proof systems do not all break the same way, and most of them do not break in the proof system itself. They break in the assumption underneath.
The dividing line is the assumption. Anything resting on a group with discrete log structure dies with the rest of the column. Hash-based proof systems rest on a hash function being hard to invert and hard to collide, and quantum does not have a Shor-style attack on that. Grover's algorithm gives a square-root speedup on brute-force search, which you cancel by doubling the output. A hash-based proof at 256-bit internal width gives 128-bit security against a quantum attacker.
So the fund-critical path goes hash-based. The spend proof is a STARK. No elliptic curve operation appears anywhere in the circuit. This is the same family of tools Drake's Ethereum work is built on, and we want to be plain about that: the technique is general, it predates anyone's branding, and using a hash-based proof system does not make this an Ethereum design. We are not importing leanVM or its stack. We are using the one class of proof system that is left standing.
One proof instead of many
The current transaction carries a CLSAG signature per input and a Bulletproof per output, with the balance enforced publicly through Pedersen commitment addition. A 2-input, 2-output transaction comes out around 3.9 KB: two RingCT CLSAG signatures at 1,120 bytes each, two non-aggregated Bulletproofs near 672 bytes each, plus commitments and ephemeral keys.
Going hash-based let us collapse all of that into one proof per transaction. The statement the proof carries, for a transaction with
minputs andnoutputs:0 ≤ v < 2^64Σ inputs = Σ outputs + feeAll of it, every input and output, in a single proof. That consolidation is available precisely because there are no curves left in the circuit. There is no cross-field arithmetic to engineer around, so there is no need for a curve cycle. The membership statement becomes a Merkle path, the key becomes
K = H(k), and the key image becomesI = H("image" ‖ k), deterministic so double-spends are caught and unlinkable so privacy holds, all inside the proof as a few more hash evaluations.For a 2-in-2-out transaction at tree depth 30, the circuit is small: roughly 64 internal-tree hashes, 5 external hashes, 128 bit-decomposition constraints for the ranges, and one balance check.
Choosing the hash that goes in the circuit
The hash inside the Merkle tree is the expensive part, because the proof has to verify each tree hash as an arithmetic circuit. The algebraic cost of that hash sets the proof's size and the prover's time. We needed a hash that is cheap to express as field arithmetic and has held up under attack. There is a whole family designed for exactly this, and a good chunk of it is in trouble.
We read the recent cryptanalysis rather than the marketing.
Griffin (Crypto 2023) is out. The FreeLunch attack recovered CICO solutions for 7 of its 10 rounds in under four hours on one core, and resultant-based follow-ups at Crypto and Asiacrypt 2024 narrowed the margins further. Full-round instances fall in the k=1 case. That is the shape of a primitive on its way to being broken, and we are not putting funds behind it.
Anemoi (Crypto 2023) is out for a quieter reason. A EUROCRYPT 2025 analysis showed that 256-bit security needs at least 41 rounds where the designers specified 37, and that figure carries no security margin of its own. When the people who built the thing undercounted the rounds, more attacks usually follow.
Poseidon2 stays in. It is the most deployed and the most attacked of the family. The Ethereum Foundation has had a $130,000 bounty open on it across 2024–2026, and the live attacks — Gröbner basis work exploiting subspace trails, Graeffe-transform attacks on the challenge instances — have broken reduced-round targets without breaking full-round production parameters. A proposed tweak closes the subspace-trail issue. StarkWare's Stwo prover does over 600,000 Poseidon2 hashes per second on an M3 Pro. Years of paid effort to break it, no full-round break, is the strongest evidence available that it holds.
Rescue-Prime is the fallback. Older, more conservative, a completed bounty program, and slower. If Poseidon2 ever falls at full rounds, the tree hash migrates to Rescue-Prime through a fork, and the rest of the design is unaffected.
Outside the circuit, for key derivation and key images and anything users actually touch, we kept SHA3-512. It is the most analyzed option we have, it is already in blocknet, and quantum does not get near it: even truncated to 256 bits for storage, preimage resistance is 2^128 against Grover, which is the floor the rest of the system sits at anyway. We use SHA3-512 rather than SHA3-256 for domain-separation headroom and truncate the deployed outputs.
The stealth address wall
This is where we lost an argument with mathematics. We wanted the whole system hash-only, including the way a sender pays a recipient who is offline. We could not have it.
A stealth address lets a sender create an output that only the recipient can recognize and spend, with no prior contact. That capability is equivalent to public-key encryption. You can build an encryption scheme out of a stealth address scheme by having the sender choose which of two addresses to pay and letting the recipient read the choice. Public-key encryption cannot be built from hash functions alone; that is a known impossibility. So a stealth address that works while the recipient is offline has to carry some asymmetric cryptography. There was no hash-only version to find.
We considered dropping stealth addresses and requiring an interaction to set up each payment, the way Grin works. That fails the basic test of a currency: someone has to be able to pay you while you are asleep. So we accepted asymmetric crypto for detection, and went looking for the post-quantum option that hurt the least.
McEliece is the conservative choice by a wide margin, and its shape matched our original wish for big keys and small per-transaction data: 96-byte ciphertexts. The problem is the 261 KB key. You cannot put that in a QR code or paste it in a chat. It needs hosting, which means either an on-chain registry or off-chain infrastructure.
We tried the on-chain registry idea and watched it fall apart for a privacy chain. A public list of every recipient's key is a public list of every participant. Registration needs a fee, and a fee needs coins, and getting coins needs someone to pay you, which needs you registered first. Registration timing and network metadata become deanonymization handles. We even sketched a service that floods the registry with decoy keys to spoil correlation, and it does not fix anything; it just makes the participant list longer. The registry was the wrong building block.
Kyber-512 avoids all of it. The 800-byte key is shareable as a QR code or a URI. The 768-byte ciphertext per output is real overhead, but the proof already sets the size of a transaction, so 768 bytes is noise against it. Choosing McEliece would shave 672 bytes off each output and cost us a key-distribution problem; that trade was not worth it once the proof, not the ciphertext, set the floor.
For distribution we reused something we already run. blocknet.id is our name service, the way sns.id works for Solana. We pointed it at Kyber keys: a name resolves to an 800-byte public key, the service answers single lookups rather than handing out the whole list, and if it goes down people fall back to sharing the raw key directly. It is a convenience layer with no power over funds. The worst it can do is go offline, which the raw-key fallback covers, or serve a wrong key, which key-pinning or a spend-key-signed registration covers.
One thing we gave up here. The current design separates a view key from a spend key, so you can hand someone read-only scanning access. In the new design the Kyber private key does the scanning and the hash-based key does the spending, both from one seed, and there is no clean way to delegate scan-only access without also handing over spend power. Watch-only wallets and auditor access have to come from somewhere else, an encrypted transaction export or a selective disclosure proof. We took that loss on purpose rather than carry a second Kyber keypair or a re-encryption scheme.
We stopped having signatures
The fear we started with was huge signatures. The way out was to stop having them. The new transaction carries no ring signature and no per-output range proof. It carries one proof. That single object stands in for all sixteen ring members on every input, the range proof on every output, and the balance check, and it proves the lot against the whole chain instead of a ring of sixteen decoys.
A single transaction proof is a hash-based STARK, and a hash-based STARK is not small in absolute terms. A FRI proof leans on Merkle authentication paths across many query rounds, and that overhead sets a floor in the tens of kilobytes even for a circuit as small as ours. Our working estimate for the spend circuit sits in that range, with the exact figure depending on the field, the FRI parameters, and how hard we recurse. That is the one number left to settle on a real prover, and we will publish it measured rather than estimated.
What stops that number from compounding is the property that made us pick this family of proofs to begin with. Hash-based proofs recurse. A block folds the proofs of all its transactions into one proof that says every transaction in the block verified, so a node syncing the chain downloads one proof per block instead of one per transaction. The per-transaction proof is what a sender broadcasts to the mempool, where a relaying node checks it on its own before it is mined; the folded block proof is what the chain stores and what a fresh node replays. This is the lever the early thinking already pointed at, when we said the way to pay down the cost of large post-quantum proofs is aggregation. It is the same lever, run with hash-based recursion in place of a curve cycle, and it lands directly on the part of blocknet that hurts, which is sync time under a 2 GB proof of work. The full proof is paid once, at relay. The chain and everyone syncing it pay the folded cost.
The keys stay small through all of this. A spending key is a 256-bit secret and its public key is a 32-byte hash. The one larger object a user holds is the 800-byte Kyber address, published once to a name. There is no 261 KB key to host and no fat per-signature blob to repeat, because there is no signature left to repeat.
Where this leaves us
The security comes down to one separation. The only non-hash assumption anywhere is Kyber, and Kyber guards privacy, not money. If Module-LWE falls to some future algorithm, an attacker learns which outputs were addressed to which key. They still cannot spend those outputs, because spending needs the hash-based key, and that rests on preimage resistance. The conservative assumption protects the thing that matters most, and the younger one only ever costs privacy.
The migration is still an open call between a hard fork that drags every existing Pedersen-committed output into a new Poseidon2 tree, and a clean relaunch. The quantum threat invalidates every existing key regardless, so a relaunch is on the table in a way it would not normally be; holders have to rotate keys either way.
Industrial cryptography
Step back from blocknet and the picture is uniform. The cryptography that secures this whole industry sits on elliptic curves, and the chains holding the most money sit on the most exposed version of it.
Bitcoin is secp256k1, the exact curve the Google and Schrottenloher circuits were demonstrated on. Every coin held at a reused address, and every coin whose public key has ever touched the chain, is a static target the day a machine can run Shor. Ethereum is no better placed: BLS signatures at the consensus layer, KZG commitments at the data layer, and ECDSA at the execution layer are all pairing or discrete-log constructions, all broken by the same algorithm. Ethereum at least has a declared plan, hash-based and aimed at 2029, which is more than most of the field can say.
Our own corner, the privacy chains, has been doing careful work that the quantum results just retired. Monero's forward path for full-chain membership proofs runs on the Helios/Selene curve cycle. Ran/Shaw was built to do that job better, and it does: 254-bit twist security on both curves against Helios/Selene's hundred-odd bits before its script bug was corrected and a little over two hundred after, chosen by a transparent search instead of landed on by accident. None of that edge survives Shor. A curve cycle is two elliptic curves, and Shor does not care which of two cycles is the more careful piece of engineering. The contest between Helios/Selene and Ran/Shaw was a contest over which broken primitive broke more gracefully, and the quantum posts settled it by breaking both at once.
That is the whole reason this design leaves curves behind on the spend path. The best curve-cycle work in the privacy space, ours included, lands on the wrong side of the line Shor draws. Hash-based proofs are the only entry in the list still standing once that line is drawn, and the price of using them is bandwidth, which is a problem we know how to chip at. The price of not using them is that the chain stops being secure the morning qday arrives.
blocknet is small enough to move before that morning. The large chains are not, and the value they carry makes a quiet migration impossible: you cannot rotate tens of millions of exposed keys without the rotation becoming the event. We would rather make the move now, while the amount at stake is survivable and the design can be argued over in the open, than inherit the position Bitcoin is walking into. The formal construction, with the circuit, the key derivation, the transaction format, and the security analysis, is written up in the protocol specification. The one number we still owe is the measured proof size, and it will land when the prover is real.
Sources