.png)
"STARKs use hashes, so they are post-quantum". The sentence is true of a commitment scheme and false of a proof system. Here is the difference, using our own zkVM as the example.
Ziren is a FRI-based zkVM. Its polynomial commitment is hash-based, its Merkle trees and transcript are Poseidon2 over the KoalaBear field, and nothing in that layer falls to a quantum computer. By the usual shorthand, that makes Ziren post-quantum. This year, when the team behind GOAT Network and ZKM audited the full GOAT stack for quantum exposure, that shorthand was the first thing to go.
Symmetric and hash-based layers protect only what they carry. A hash commitment, a garbled circuit, a hashlock, a Lamport signature: each survives Shor's algorithm, and each is only as quantum-safe as the statement inside it. If the thing being committed, garbled or encrypted is an elliptic-curve or pairing assertion, the composition breaks when the curve does, and no hash is inverted in the process.
The audit found four instances of this pattern in one bridge stack, three existing and one prospective:
The third case is the sharpest. The vocabulary (witness encryption, garbled circuit, hashlock, Lamport) argues for safety, three of the four onchain primitives are safe, and the proof is a clean reduction. The pairing survives in the relation being encrypted against, which is the one place the terminology does not point. The rule that comes out of it: read the security theorem, not the primitive list.
Applying that rule to Ziren produced one clarification and one finding.
The clarification, because the rule cuts both ways. FRI and Poseidon2 are hash-based, and that settles the quantum question for those layers: Shor does not touch them, and Grover only halves preimage security. It does not settle the classical one. An algebraic hash's security comes from its parameters, the width, the S-box degree and the number of full and partial rounds, and the sparse partial-round structure that makes Poseidon2 cheap to arithmetize is under active cryptanalysis, with several subspace-trail and degree-annihilation results published this year. Post-quantum and secure are different claims. A hash earns the second one from its round count, not from being a hash, and anyone auditing a proof system for quantum exposure should check the concrete instantiation while they are in there.
The finding is that the offline memory-consistency argument is not hash-based at all. Ziren checks that memory reads match memory writes with an elliptic-curve multiset hash: memory values are hashed to curve points and the points are accumulated in an EC subgroup. Soundness holds if discrete log is hard. We have tracked this openly as Ziren issue #276 since August 14th, 2025. Against a quantum adversary, the attack is not on FRI. It is on the memory check, and the execution proof falls with it.
There are two ways to close it, and both are in the tree today.
The first is an additive multiset digest in the LtHash family. The reference point is Secure Challenge Derivation in ZisK, which instantiates LtHash over Z_p^n and reduces multiset collision resistance to the Short Integer Solution problem, a lattice problem believed to stay hard against quantum adversaries. ZisK applies it to distributed challenge derivation rather than memory checking, so what carries over is the construction, not the deployment. Our feat/lthash branch prototypes a memory-checking version across the core machine and the recursion circuits, with its own parameters and its own soundness argument. Its collision bound currently rests on a random-matrix heuristic rather than a completed reduction, which the branch's design note says in as many words. Until that reduction is written, this route should be described as replacing a discrete-log assumption, not as having replaced it with an established lattice one.
The second is to revert the memory argument to LogUp. Memory consistency was a LogUp lookup between the global and local memory tables before the multiset hash replaced it, and Ziren still uses LogUp for every other cross-chip check. We have written up both pieces of that machinery already, in The Logup-GKR Protocol and Offline memory checking in zkVM. A LogUp memory argument, with GKR proving the fractional sums, is field arithmetic committed under FRI and nothing else. It does not swap one assumption for another. It removes the assumption. The cost is that with execution split across shards, the challenge has to be derived after every shard's read and write sets are committed, which replaces the challenge-free accumulation the multiset hash gave us with a two-pass derivation across shards. That is engineering inside a mechanism Ziren already ships, not a new primitive.
The difference between the two routes: with the lattice hash, Ziren's soundness rests on hashes and a lattice assumption. With LogUp-GKR, it rests on hash security alone.
Our recommendation is the second route wherever the sharded challenge derivation is acceptable, because it is the one that shrinks the assumption set rather than exchanging it, and because LogUp-GKR is machinery Ziren already ships and has already written up. The decision is not made yet, and we would rather say that than imply otherwise. What we will commit to is the standard the choice has to meet: whichever route closes #276, it ships with a stated assumption and a written reduction, not a heuristic.
The finding that matters most for Bitcoin layer 2s is about a choice Ziren made long before anyone was thinking about quantum.
A post-quantum verifier on Bitcoin is usually assumed to need OP_CAT, and therefore a soft fork. Script can do arithmetic but cannot hash a concatenation: OP_CAT is disabled, so a script cannot assemble the two-child preimage a SHA256 Merkle step hashes. That dependency belongs to the byte hash, not to Merkle verification. An algebraic hash like Poseidon2 is a permutation over field elements. Compressing two children means feeding sixteen field elements into a width-16 permutation, which is sixteen stack items handed to an arithmetic routine, and script already emulates field arithmetic at 254 bits because BitVM does. Over a 31-bit field, each element fits a script number directly.
Ziren commits with Poseidon2 over KoalaBear. So a Ziren STARK proof is, in principle, verifiable on the Bitcoin that exists today.
In principle became a number this summer. Applied PQC built a Poseidon2 permutation and a WHIR opening verifier in Bitcoin script, with zero uses of OP_CAT or any other disabled opcode, and ran it end to end against a real Plonky3 prover. The implementation is open, at bitcoin-stark-verifier, and every figure below is the length of a script one of its tests executes. The permutation is 572,228 bytes of script and nothing else in the verifier is within one percent of it. At 100-bit security with 22 bits of grinding the full verifier is 979 permutations, 560 MB, about 140 blocks, and it cuts into 1,958 disprove chunks, the same order as BitVM2's own leaf count. The shape holds across configurations. On the 2^20 example, 20 queries at folding factor 4, the verifier's 2,162 permutations are 97% query work: 60% Merkle paths and 37% leaf hashing, which tells you where optimization goes and where it does not.
Four caveats travel with the figure. It verifies a WHIR opening and its sumcheck, not a zkVM execution proof, so it is a lower bound for what a bridge would actually run. The chunk count prices the on-chain spend and the number of one-time keys but not generating them, which is roughly a quarter of a million hash chains and the cost BitVM2 deployments actually struggle with. It also covers only the permutations: the arithmetic between them does not decompose into steps, 2% of the verifier, still 11 MB at this configuration, with no step boundary inside it. And the configuration measured uses WHIR's capacity-bound soundness regime, which rests on the unproven half of Conjecture 4.12.
The alternative family, module-lattice arguments in the LaBRADOR line, commits algebraically and has no per-level hash to pay, at the cost of heavier verifier work and a change to Ziren's commitment scheme. It has not been written in script yet. That is the measurement that decides the choice, and it is next.
Three things, in order. Close #276 and remove Ziren's remaining non-hash assumption. Measure a Ziren-targeted verifier in script, with Applied PQC, and the module-lattice alternative alongside it. And support the re-targeting of the GOAT Network bridge away from Groth16, which is the item that depends on the first two.
When it is done, Ziren's soundness will rest on stated assumptions with written reductions and the proofs it produces can be verified by Bitcoin script under today's consensus rules.
Applied PQC is the open-source post-quantum research initiative of the engineers behind ZKM. The full analysis is at appliedpqc.io and is maintained in the pqc-research repository.
"STARKs use hashes, so they are post-quantum". The sentence is true of a commitment scheme and false of a proof system. Here is the difference, using our own zkVM as the example.
Ziren is a FRI-based zkVM. Its polynomial commitment is hash-based, its Merkle trees and transcript are Poseidon2 over the KoalaBear field, and nothing in that layer falls to a quantum computer. By the usual shorthand, that makes Ziren post-quantum. This year, when the team behind GOAT Network and ZKM audited the full GOAT stack for quantum exposure, that shorthand was the first thing to go.
Symmetric and hash-based layers protect only what they carry. A hash commitment, a garbled circuit, a hashlock, a Lamport signature: each survives Shor's algorithm, and each is only as quantum-safe as the statement inside it. If the thing being committed, garbled or encrypted is an elliptic-curve or pairing assertion, the composition breaks when the curve does, and no hash is inverted in the process.
The audit found four instances of this pattern in one bridge stack, three existing and one prospective:
The third case is the sharpest. The vocabulary (witness encryption, garbled circuit, hashlock, Lamport) argues for safety, three of the four onchain primitives are safe, and the proof is a clean reduction. The pairing survives in the relation being encrypted against, which is the one place the terminology does not point. The rule that comes out of it: read the security theorem, not the primitive list.
Applying that rule to Ziren produced one clarification and one finding.
The clarification, because the rule cuts both ways. FRI and Poseidon2 are hash-based, and that settles the quantum question for those layers: Shor does not touch them, and Grover only halves preimage security. It does not settle the classical one. An algebraic hash's security comes from its parameters, the width, the S-box degree and the number of full and partial rounds, and the sparse partial-round structure that makes Poseidon2 cheap to arithmetize is under active cryptanalysis, with several subspace-trail and degree-annihilation results published this year. Post-quantum and secure are different claims. A hash earns the second one from its round count, not from being a hash, and anyone auditing a proof system for quantum exposure should check the concrete instantiation while they are in there.
The finding is that the offline memory-consistency argument is not hash-based at all. Ziren checks that memory reads match memory writes with an elliptic-curve multiset hash: memory values are hashed to curve points and the points are accumulated in an EC subgroup. Soundness holds if discrete log is hard. We have tracked this openly as Ziren issue #276 since August 14th, 2025. Against a quantum adversary, the attack is not on FRI. It is on the memory check, and the execution proof falls with it.
There are two ways to close it, and both are in the tree today.
The first is an additive multiset digest in the LtHash family. The reference point is Secure Challenge Derivation in ZisK, which instantiates LtHash over Z_p^n and reduces multiset collision resistance to the Short Integer Solution problem, a lattice problem believed to stay hard against quantum adversaries. ZisK applies it to distributed challenge derivation rather than memory checking, so what carries over is the construction, not the deployment. Our feat/lthash branch prototypes a memory-checking version across the core machine and the recursion circuits, with its own parameters and its own soundness argument. Its collision bound currently rests on a random-matrix heuristic rather than a completed reduction, which the branch's design note says in as many words. Until that reduction is written, this route should be described as replacing a discrete-log assumption, not as having replaced it with an established lattice one.
The second is to revert the memory argument to LogUp. Memory consistency was a LogUp lookup between the global and local memory tables before the multiset hash replaced it, and Ziren still uses LogUp for every other cross-chip check. We have written up both pieces of that machinery already, in The Logup-GKR Protocol and Offline memory checking in zkVM. A LogUp memory argument, with GKR proving the fractional sums, is field arithmetic committed under FRI and nothing else. It does not swap one assumption for another. It removes the assumption. The cost is that with execution split across shards, the challenge has to be derived after every shard's read and write sets are committed, which replaces the challenge-free accumulation the multiset hash gave us with a two-pass derivation across shards. That is engineering inside a mechanism Ziren already ships, not a new primitive.
The difference between the two routes: with the lattice hash, Ziren's soundness rests on hashes and a lattice assumption. With LogUp-GKR, it rests on hash security alone.
Our recommendation is the second route wherever the sharded challenge derivation is acceptable, because it is the one that shrinks the assumption set rather than exchanging it, and because LogUp-GKR is machinery Ziren already ships and has already written up. The decision is not made yet, and we would rather say that than imply otherwise. What we will commit to is the standard the choice has to meet: whichever route closes #276, it ships with a stated assumption and a written reduction, not a heuristic.
The finding that matters most for Bitcoin layer 2s is about a choice Ziren made long before anyone was thinking about quantum.
A post-quantum verifier on Bitcoin is usually assumed to need OP_CAT, and therefore a soft fork. Script can do arithmetic but cannot hash a concatenation: OP_CAT is disabled, so a script cannot assemble the two-child preimage a SHA256 Merkle step hashes. That dependency belongs to the byte hash, not to Merkle verification. An algebraic hash like Poseidon2 is a permutation over field elements. Compressing two children means feeding sixteen field elements into a width-16 permutation, which is sixteen stack items handed to an arithmetic routine, and script already emulates field arithmetic at 254 bits because BitVM does. Over a 31-bit field, each element fits a script number directly.
Ziren commits with Poseidon2 over KoalaBear. So a Ziren STARK proof is, in principle, verifiable on the Bitcoin that exists today.
In principle became a number this summer. Applied PQC built a Poseidon2 permutation and a WHIR opening verifier in Bitcoin script, with zero uses of OP_CAT or any other disabled opcode, and ran it end to end against a real Plonky3 prover. The implementation is open, at bitcoin-stark-verifier, and every figure below is the length of a script one of its tests executes. The permutation is 572,228 bytes of script and nothing else in the verifier is within one percent of it. At 100-bit security with 22 bits of grinding the full verifier is 979 permutations, 560 MB, about 140 blocks, and it cuts into 1,958 disprove chunks, the same order as BitVM2's own leaf count. The shape holds across configurations. On the 2^20 example, 20 queries at folding factor 4, the verifier's 2,162 permutations are 97% query work: 60% Merkle paths and 37% leaf hashing, which tells you where optimization goes and where it does not.
Four caveats travel with the figure. It verifies a WHIR opening and its sumcheck, not a zkVM execution proof, so it is a lower bound for what a bridge would actually run. The chunk count prices the on-chain spend and the number of one-time keys but not generating them, which is roughly a quarter of a million hash chains and the cost BitVM2 deployments actually struggle with. It also covers only the permutations: the arithmetic between them does not decompose into steps, 2% of the verifier, still 11 MB at this configuration, with no step boundary inside it. And the configuration measured uses WHIR's capacity-bound soundness regime, which rests on the unproven half of Conjecture 4.12.
The alternative family, module-lattice arguments in the LaBRADOR line, commits algebraically and has no per-level hash to pay, at the cost of heavier verifier work and a change to Ziren's commitment scheme. It has not been written in script yet. That is the measurement that decides the choice, and it is next.
Three things, in order. Close #276 and remove Ziren's remaining non-hash assumption. Measure a Ziren-targeted verifier in script, with Applied PQC, and the module-lattice alternative alongside it. And support the re-targeting of the GOAT Network bridge away from Groth16, which is the item that depends on the first two.
When it is done, Ziren's soundness will rest on stated assumptions with written reductions and the proofs it produces can be verified by Bitcoin script under today's consensus rules.
Applied PQC is the open-source post-quantum research initiative of the engineers behind ZKM. The full analysis is at appliedpqc.io and is maintained in the pqc-research repository.
