> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qbtc.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Quantum Resistance (ML-DSA)

> QBTC's two-layer post-quantum design: ML-DSA (NIST FIPS 204) at consensus, and PLONK zero-knowledge proofs at the claim layer.

QBTC achieves quantum resistance through two independent mechanisms operating on different layers of the chain.

## At the consensus layer: ML-DSA

The chain's consensus signing path uses **ML-DSA** (Module-Lattice-Based Digital Signature Algorithm), formerly known as CRYSTALS-Dilithium, standardized by NIST as **FIPS 204**.

Every validator's consensus key is an ML-DSA key. Every consensus vote, every block-commit signature, every gossip message is signed with ML-DSA. There is no ECDSA or Ed25519 dependency anywhere in the consensus path.

Implemented via a fork of CometBFT at `github.com/btcq-org/cometbft`, which adds a `crypto/mldsa` package and routes signing through it.

If validators signed with Ed25519, a quantum-capable adversary could forge a validator signature and rewrite chain history. ML-DSA is lattice-based and is believed secure against both classical and quantum attacks at NIST security level 3 (ML-DSA-65).

### Size and bandwidth

ML-DSA signatures are larger than Ed25519:

* ML-DSA-65 signature: \~3.3 KB.
* ML-DSA-65 public key: \~2.0 KB.
* Ed25519 signature: 64 bytes.
* Ed25519 public key: 32 bytes.

Block size and bandwidth costs are higher accordingly. The chain absorbs the cost as part of the design.

## At the claim layer: ZK proofs

A user claiming QBTC submits a zero-knowledge proof that they control the private key for a Bitcoin address, **without** broadcasting the public key. Once a Bitcoin public key is broadcast (during a normal spend, for example), it becomes a target for Shor's algorithm.

The proof system is **PLONK**, a SNARK-style construction. The circuit verifies:

* Knowledge of a Bitcoin private key.
* That the corresponding public key hashes (via Hash160) to a specific Bitcoin address.
* Binding to a specific destination QBTC address (so a proof can't be replayed against a different destination).

Public inputs (revealed on-chain):

* Hash160 of the Bitcoin address.
* Destination QBTC address.

Hidden inputs (kept secret):

* Bitcoin public key.
* Bitcoin private key.
* ECDSA signature.

### Verification cost and proof generation

The on-chain verifier is fast (\~2–5 ms verification per proof, proof size \~1 KB). Verification cost is what matters for chain throughput.

Proof generation happens client-side. Wallets handle it natively. Independent operators also run hosted "proof service" endpoints that wallets can use to offload computation on constrained devices. The local CLI prover (`zkprover`) is available for users who want to generate proofs themselves.

The trusted setup for the PLONK circuit reuses the Hermez/Polygon Powers of Tau 2²¹ ceremony, an existing public ceremony with multiple participants.

## Why both layers

Either alone is insufficient. If only consensus were ML-DSA, the act of broadcasting your BTC public key during a claim would expose it to a quantum attacker who could race you for the BTC on Bitcoin Legacy before your QBTC claim settles. If only claims used ZK, validators could be quantum-attacked and the chain could be rewritten.

Together, the chain is post-quantum end to end.

## References

* NIST FIPS 204: ML-DSA specification.
* `github.com/btcq-org/cometbft`: the forked CometBFT.
* `x/qbtc/zk/`: PLONK circuits and on-chain verifier in the chain code.
* [Protocol Specification §1, §2.3](../research/protocol-spec.md).