We audited the GOAT Network stack for post-quantum exposure, surface by surface. Six of the seven surfaces carry cryptography a quantum computer would break. This is the map: what is exposed, what is already safe, and the order we are fixing the rest.
GOAT Network exists because of one thesis: the next economy should be secured by Bitcoin. We have spent years building a system that settles to Bitcoin, proves its state to Bitcoin, and moves BTC through a bridge whose worst case is decided by Bitcoin script rather than by a committee's good behaviour. All of that only means something if Bitcoin's security holds. So the quantum question is not a side topic for us. It is a question about the foundation everything else is built on.
Bitcoin's own answer is in progress and incomplete. BIP-360 proposes an output type that never commits a bare public key onchain, and its text is explicit that it does not introduce a post-quantum signature scheme. BIP-361 proposes a pre-announced sunset of legacy ECDSA and Schnorr, and its dependency field reads "TBD Post Quantum Signature BIP", a document that does not yet exist. A candidate for that slot now exists: SHRINCS, a hash-based scheme published as a draft in August, though not yet in the BIPs repository. Our research team has written a full explainer of it. The same BIP states that as of March 1st over 34% of all bitcoin have revealed a public key onchain. That is the environment every Bitcoin layer 2 operates in, whether or not it says so.
BIP-361 also carries a clock. Its Phase A, about 160,000 blocks or roughly three years after activation, forbids sending to quantum-vulnerable addresses. Every GOAT deposit address, on either bridge, is derived from a secp256k1 or Schnorr custody key. If BIP-361 activates, our deposit path has about three years to move to a post-quantum output type, independently of when a quantum computer arrives. That deadline, not the quantum computer, is what sets our schedule.
Sources: BIP-361 (bitcoin/bips), field verified September 2026; Applied PQC (appliedpqc.io).
We decided to say so. This year our engineering team read every cryptographic surface in the GOAT stack, from the peg outputs on Bitcoin to the precompiles in the EVM, and wrote down what is exposed, what is not, and who can fix each part. The full analysis is published at Applied PQC, the open-source post-quantum research initiative our engineers run. This article is the short version.
A layer 2 is a different problem
Most post-quantum analysis treats a chain as one cryptographic system: one signature scheme, one consensus mechanism, one governance process to change them. A Bitcoin layer 2 is not that. It settles to a base layer it cannot change. It borrows a consensus stack from a third ecosystem and inherits that ecosystem's migration path. And it runs a bridge whose trust root is cryptography of its own choosing, which is also the highest-value target in the system.
So the work divides in two. There are surfaces the layer 2 can fix on its own schedule, and there are surfaces where the only available move is to bound the exposure and press upstream. We mapped seven:
Source: Applied PQC, Post-quantum migration for Bitcoin layer 2s (appliedpqc.io), verified September 2026.
Three different parties hold the fix. Only the middle group is ours to schedule. That framing decided the order of everything below.
What we found
Six of the seven surfaces carry cryptography that falls to Shor's algorithm.
The sharpest exposure is peg custody. The bridge committee signs with MuSig2 over a Taproot key path, and a Taproot output commits its output key in the scriptPubKey at the moment the output is created, not when it is spent. So the aggregated public key sits onchain, in the clear, for the entire life of the UTXO. An adversary with a cryptographically relevant quantum computer recovers the secret from that key and spends. No proof is forged and no committee member is compromised. Choosing an unspendable internal key does not help, because consensus checks the signature against the output key and never asks how it was built. The fix is BIP-360, which is Bitcoin's timeline. What we can do unilaterally is shrink the window: rotate custody outputs, cap the value in any one output, and avoid long-lived connector outputs. We will publish that policy.
The bridge proof system is exposed at three layers, and this is where the finding gets uncomfortable. The pipeline is: Ziren produces a STARK proof, that proof is wrapped into a Groth16 proof over the BN254 curve, and the Groth16 verifier is what runs in Bitcoin script. The Groth16 wrap is pairing-based and breaks. The garbled-circuit stack in BitVM3 garbles a Groth16 verifier, so the garbling is safe and the statement inside it is not. And inside Ziren, the offline memory-consistency check uses an elliptic-curve multiset hash that depends on discrete-log hardness, which the Ziren team has tracked openly as issue #276 since August 14th, 2025. A quantum adversary would not attack FRI. It would forge the memory check, and the execution proof would fall with it.
The relayer carries three key types: secp256k1 and Schnorr attestation keys, a secp256k1 transaction key, and a BLS12-381 vote key. Consensus keys are secp256k1 through CometBFT. EVM accounts are ECDSA, as on every EVM chain. And goat-geth carries the full upstream set of curve and pairing precompiles, which are consensus rules with immutable callers and can only be fixed upstream.
We also found that our BitVM3 work, including Deferred Binding, does nothing for the post-quantum position. It answers the question it was asked, which was onchain cost, and it produces an onchain surface that is hash-based. But the witness encryption is keyed to the Groth16 verification equation, and the security reduction carries an explicit discrete-log term. We are not counting it as post-quantum progress, and we would ask anyone else describing a hash-based bridge to apply the same test.
Source: Applied PQC, Post-quantum migration for Bitcoin layer 2s (appliedpqc.io), verified September 2026.
What is already safe
The Bitcoin-side plumbing of the bridge is post-quantum today. BitVM2 carries values between script fragments with Winternitz one-time signatures, which are hash-based. The hashlocks and Lamport commitments are hash-based. The garbling layer is symmetric. Ziren's polynomial commitment, FRI, is hash-based.
The lesson is the one that organised the whole audit: hash-based layers protect only what they carry. Every one of those safe layers is wrapping or transporting an elliptic-curve assertion, and the bridge is only as quantum-safe as that assertion. So the work is not a rewrite. It is two contained swaps, the memory check inside Ziren and the pairing verifier the bridge is built around, plus a set of key migrations that are mostly key-type changes and dependency upgrades.
Source: Applied PQC, Post-quantum migration for Bitcoin layer 2s (appliedpqc.io), verified September 2026.
The order we are doing it in
Ownership and severity set the order.
Inventory every signature and proof verification path, and add tests asserting no fixed signature-length assumptions. We found one: a check in the relayer that rejects any signature not exactly 64 bytes long. An ML-DSA-65 signature is 3,309 bytes. Checks like that are small, load-bearing and invisible until something fails.
Relayer attestation keys. Add an ML-DSA-65 variant to the attestation key type, make length checks per-variant, and roll out with dual attestation so there is rollback at every step. Highest value per unit of control, and the key type is already an extensible union. The BLS12-381 vote key needs no post-quantum replacement: the MPC bridge it serves is being retired in favour of the BitVM bridge.
Peg custody exposure policy. Written, enforced, published.
Ziren issue #276, with ZKM (our zk-focused R&D branch). Two routes exist: an additive multiset digest in the LtHash family, prototyped on a branch, or reverting the memory argument to the LogUp lookup Ziren already uses for every other cross-chip check, which leaves the hash as the only assumption. The route is not chosen yet. This gates everything above it, so it comes before the verifier work.
Stop verifying a pairing on Bitcoin. Re-target the proof pipeline and the garbling stack away from Groth16 over BN254. This is the hardest item and it ships last. More on it below.
Consensus keys. Upgrade the Cosmos SDK to 0.55, which ships ML-DSA-65 as an opt-in validator key type together with key rotation, then rotate validators and re-tune block-size limits for 3,309-byte signatures. GOAT runs the upstream SDK rather than a fork, so this is a dependency upgrade, not a rebase. This phase is the furthest along: the rotation mechanism is built and measured, and the design, gates and benchmarks are public in Post-Quantum Consensus Keys on GOAT.
Execution layer. Close goat-geth's gap to upstream, which is the delivery channel for Ethereum's post-quantum account and precompile work, and inventory which deployed contracts call the pairing precompiles and whether each one is upgradeable. An immutable caller can be identified now but never migrated later.
Source: Applied PQC, Post-quantum migration for Bitcoin layer 2s (appliedpqc.io), verified September 2026.
Item 5 is the one people will ask about, so here is where it stands.
Verifying a post-quantum proof on the Bitcoin that exists
The usual objection to a hash-based verifier on Bitcoin is that it needs OP_CAT, and therefore a soft fork. That turns out to be a property of the hash, not of the proof system. Script cannot concatenate two 32-byte children into the input a SHA256 Merkle step needs. But an algebraic hash like Poseidon2 is a permutation over field elements, and script can emulate field arithmetic today, because BitVM already does. Ziren commits with Poseidon2 over a 31-bit field. Choose the algebraic hash and the soft-fork dependency disappears.
So it was measured. Applied PQC built a STARK opening verifier (Poseidon2 plus a WHIR opening) in Bitcoin script with zero uses of OP_CAT or any other disabled opcode, and ran it end to end against a real prover. At 100-bit security with 22 bits of grinding it is 979 hash permutations, which cut into 1,958 disprove chunks, each fitting a standard transaction with its state commitments. That is the same order of magnitude as BitVM2's own leaf count, and it settles the question that mattered: the route is viable under today's consensus rules. It is a lower bound rather than a forecast. It verifies a WHIR opening and its sumcheck, not a zkVM execution proof, and the chunk count prices the spend and the one-time keys but not generating them, which is on the order of a quarter of a million hash chains. What remains unmeasured is the module-lattice alternative, which has no per-level hash to pay. That measurement decides the row, and it is next.
Source: Applied PQC, bitcoin-stark-verifier (github.com/AppliedPQC), measured August 2026.
Why this belongs on the public record
We could have written the reassuring version. Most of the surfaces above have a true sentence available about a hash-based layer. We chose the inventory instead, because the entire point of building on Bitcoin is that the security has to be real, and the base layer's migration is going to be the hardest coordination problem this industry has faced. A layer 2 that wants to be part of the economy secured by Bitcoin should be doing its half of the work in the open, and pressing upstream on the other half.
If you build on GOAT Network, nothing changes for you today. If you are building a Bitcoin layer 2, the framework is yours to use.
The full analysis, with sources, measurements and open items, is at appliedpqc.io.
