Post-Quantum Citrea

Recent research [1] [2] has reignited the looming potential of quantum attacks on the very foundation of modern cryptography: the elliptic curves.

As a layer secured by Bitcoin, Citrea shares the concern of the broader Bitcoin community that quantum computers could eventually break the elliptic curve cryptography Bitcoin relies on. However, our preliminary analysis shows that Citrea is well-positioned to adapt to a post-quantum Bitcoin environment.

Making Citrea Post-Quantum Across Three Stacks

Citrea consists of three core components vulnerable to quantum attacks. While two of these can be made quantum-resistant through increased proof sizes and new precompiles, the Clementine bridge is directly tied to the Bitcoin base layer. Because Clementine relies on Bitcoin transactions, specifically Schnorr signatures, a fully post-quantum Citrea would ultimately require a Bitcoin soft fork.

Transitioning Citrea to a post-quantum state requires a coordinated roadmap across the execution environment, the proving infrastructure, and the Clementine bridge.

1. Execution Environment

Citrea utilizes the EVM for its execution environment, where ECDSA is the main form of transaction authorization. To combat quantum threats there, Citrea could leverage Account Abstraction (AA), which allows users to define their own custom authorization logic.

We have already deployed a smart account on the Citrea testnet that verifies ML-DSA-44 signatures using Kohaku [3]:

0x8D87f958fb96cdAF61dB707F980759B3C5E23845

While functional, the current overhead is significant; verifying a single ML-DSA-44 signature consumes approximately 25 million gas. To make this practical for everyday use, our research is focused on implementing precompiles to optimize verification efficiency and lower costs for users.

2. Proving Infrastructure

The core of Citrea’s rollup infrastructure, including batch proofs, light client proofs, and bridge proofs, is the most quantum-resistant part of the Citrea stack. Citrea uses RISC Zero's zkVM, which generates STARK proofs. Because STARKs rely on hash functions rather than elliptic curves, they are inherently post-quantum secure.

In our current architecture, we wrap these STARKs into SNARKs to minimize the data footprint on Bitcoin. In a post-quantum scenario, we would transition to wrapping them in PQ-friendly SNARKs [4]. Based on our modeling of mainnet data, this transition would result in roughly a 50% increase in the total bytes posted to Bitcoin daily.

Furthermore, because batch proving aggregates multiple transactions into a single proof, we effectively remove individual signatures from the on-chain data. This allows us to avoid the "signature size explosion" typically associated with PQ schemes.

3. Clementine Bridge

The security and operation of the Clementine bridge are directly linked to the Bitcoin base layer. Without a Bitcoin consensus change, a fully post-quantum Clementine bridge is technically impossible. This is because Bitcoin only authorizes transactions via Schnorr or ECDSA, both of which are vulnerable to quantum attacks.

The following roadmap assumes a soft fork that adds a PQ signature scheme to Bitcoin:

• Presigning and MuSig2: Clementine heavily relies on presigning and MuSig2 to aggregate signatures efficiently. Most PQ signature schemes do not support this level of aggregation, meaning the bridge would naturally become more "data-heavy" as we'd move toward individual signatures.
• PQ proof verification in BitVM: For optimistic verification of ZK proofs on Bitcoin, we can construct a garbled circuit that can verify PQ proof statements. Current literature suggests a proof size of ~14 kB at 80 bits of security. In a BitVM3 context, where a Garble Circuit requires signing each proof bit via Lamport Signature, this results in an on-chain proof size of roughly 7.6 MB.

While a 7.6 MB transaction is large, it remains feasible for "pessimistic" cases where proofs are only revealed if a bridge operator acts maliciously. However, further research is required to optimize garbling times and maintain a 128-bit security standard.

Conclusion

The path to a Post-Quantum Citrea is clear, if challenging. Two of our three core components, execution and proving, can be made PQ-ready through moderate protocol upgrades, such as new precompiles and the adoption of PQ-friendly SNARKs.

However, making the Clementine bridge quantum resistant remains gated by a Bitcoin soft fork. We’re closely following the quantum research field and the efforts of the Bitcoin community, and we stand ready to ensure Citrea remains secure for decades to come.

References:

[1] https://arxiv.org/abs/2603.28846

[2] https://arxiv.org/abs/2603.26160

[3] https://github.com/ethereum/kohaku

[4] https://hackmd.io/@clientsideproving/pq-snark-verifier

Written by Ekrem Bal. Edited by Tugce Smith.