What it is. Mina is a digital money network famous for shrinking its whole history into a tiny proof small enough to hold on a phone, and today none of the math guarding it can stand up to a future quantum computer.
What we found. A quantum computer would not only let someone forge payments, it would also break the one tiny proof that the network leans on instead of storing its full past, and the team behind Mina knows how to fix this but has not started, named a date, or shipped any protection.
Why it matters. If that proof can be faked, an attacker could rewrite what the network claims happened, so holders and institutions cannot count on this being repaired on time, and the small-proof design that people sometimes mistake for quantum protection is exactly what is most exposed.
Mina has one of the most cryptographically sophisticated stacks in the L1 cohort, Pickles recursive composition over the Pasta cycle, key-prefixed Schnorr-Pallas, Poseidon for in-circuit hashing, audited wallet supply chain, and every public-key primitive is Shor-broken. A Pasta-curve break invalidates not just signatures but the soundness of the 22KB recursive proof that stands in for the chain's history.
Summary
Mina's stack is built on Schnorr signatures over the Pallas curve, Pickles recursive composition over the Pasta cycle (Pallas/Vesta) using Halo-style Inner Product Argument commitments, no pairings, no trusted setup, and no post-quantum security: IPA reduces to discrete-log, broken by Shor on either Pasta curve. Every account public key, every Pickles/Kimchi proof, and the 22KB succinct chain proof itself sit on the same Pasta-curve assumption. A break invalidates not only signatures but the recursive proof that substitutes for the chain's history. Mina has shipped two coordinated mainnet upgrades (Berkeley 2024-06-04, Mesa scheduled 2026 with unanimous on-chain MIP approval December 2025) and runs a research-grade cryptography team at o1Labs, yet zero PQ primitives, zero published PQ position, zero PQ-named milestone. Mesa MIPs 6–9 are entirely throughput/capacity, no primitive change. Forge subtotal 16/75; Decrypt subtotal 4/25. Gate 1a-Sig FAIL, Gate 1a-KEM FAIL. X+Y exits the risk window (>2035), the Crisis Zone (>2030), and the compliance window simultaneously. QRI 23, Band 3 Planning, Migration Stage 1.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition at any layer; Schnorr/Pallas is the sole account-signing scheme with no PQ co-signer announced
- Gate 1a, Hybrid KEM: FAIL , validator p2p libp2p and GraphQL RPC use classical TLS without hybrid PQ KEM
- Gate 1b, Commit-to-hash: COND , no OR-composition declared; commit-to-hash gate moot until 1a-Sig OR-composition exists
- Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts within 48 hours
- Gate 3, Primitive naming: PASS , Schnorr over Pallas, Pasta-IPA Halo2, Pickles recursive composition, Ouroboros Samasika VRF, Poseidon, Blake2b named with mechanism
Burn-vs-rescue policy on file
Declared option f, Undeclared. No foundation statement on policy for quantum-vulnerable historical state, no STARK-rescue path proposed, no rate-limit canary, no optional-migration framework. The recursive-proof-as-history feature creates a unique policy question (a Pasta break invalidates not just signatures but the chain's compactness premise) that has no published policy answer.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 40 / 100
o1Labs and the MinaProtocol/mina repository publish curve parameters and explicit Pasta cycle structure (Pallas scalar field = Vesta base field). One of the most thoroughly documented cryptographic stacks in this profile.
Schnorr signature scheme over the Pallas curve (key-prefixed, batch-verification-friendly variant) for account signing · Pickles recursive composition built on Kimchi (UltraPLONK variant) over the Pasta cycle (Pallas + Vesta) · Halo-style Inner Product Argument (IPA) polynomial commitment scheme, no trusted setup, no pairings · Poseidon hash (poseidon_3w variant) for in-circuit hashing and Schnorr message-hash derivation · Blake2b for transaction-level hashing and Schnorr nonce derivation · Verifiable Random Function (VRF) on Pallas for Ouroboros Samasika slot-leader selection Schnorr over Pallas (account signatures)→ Shor-break-via-DL-without-pairingsKimchi PLONK over Pasta with IPA commitments→ Shor-break-via-DL-without-pairings (IPA security reduces to discrete-log on Pallas/Vesta)Pickles recursive composition (Pasta-IPA Halo2 family)→ Shor-break-via-DL-without-pairingsPasta-VRF→ Shor-break-via-DL-without-pairingsPoseidon→ Grover-weaken (Tier 4 cryptanalytic maturity)Blake2b-256→ Grover-weaken to 128-bit
Zero PQ-safe families. Every public-key primitive in active use sits in the discrete-log family on the Pasta cycle.
No NIST-PQC primitive present. Score is structurally 0.
Least Authority audit of Auro Wallet extension (2021); o1js v2.0 underwent independent audit (2024). No machine-checked formal verification in the Formosa-Crypto / EasyCrypt sense for the proving stack itself. Constant-time inherited from standard library implementations. Library provenance: o1-labs/proof-systems (Rust), MinaProtocol/mina (OCaml + Rust). Stateless across stack. Cryptanalytic tier: Schnorr/Pallas DL Tier 1, Kimchi-PLONK + IPA Tier 3, Poseidon Tier 4, Blake2b Tier 2.
2 Quantum Recovery Exposure weight 10% 20 / 100
Mina account addresses are 32-byte compressed Pallas points; the public key is revealed at first transaction emission. Every account that has ever signed a transaction has its full Schnorr/Pallas public key on-chain and indefinitely Shor-recoverable.
Mina mainnet launched 2021-03-23. ~5 years of cold Schnorr/Pallas keys persist on-chain. No native equivalent to Bitcoin's P2PKH cold-storage hash-protection: account addresses are public-key encodings rather than hashes-of-public-keys.
Every historical Schnorr/Pallas signature is forgeable retroactively post-Shor. Mina-specific amplification: the 22KB succinct chain proof is a recursive Pickles/Kimchi proof whose soundness reduces to the discrete-log problem on Pallas/Vesta. A Shor break on either Pasta curve does not merely forge individual signatures, it makes the chain's integrity proof itself forgeable.
Validator p2p (libp2p with classical handshake), GraphQL RPC over standard TLS (X25519/ECDH key agreement), and bridge-relay channels all use classical key exchange. No hybrid PQ KEM deployed at any transport surface.
3 Metadata, Anonymity & Confidentiality weight 13% 31 / 100
Pseudonymous in the Bitcoin/Ethereum sense at the account-tx layer. The succinct-blockchain design hides full historical state from light clients but the public-tx graph (sender/receiver Pallas addresses, amounts, timestamps) remains fully observable to archive nodes and explorers. zkApps optionally use ZK to hide application-layer state.
Top-3 RPC concentration: o1Labs nodes, block-producer GraphQL endpoints, community relay nodes; concentration is not measured publicly but the small block-producer set materially concentrates mempool observability. libp2p gossip with no privacy-preserving transport layer.
Bridge activity is limited at evaluation date. The lambdaclass mina_bridge / Aligned Layer integration for Mina-to-Ethereum proof verification is documented as research/devnet. Wrapped-MINA representations on Ethereum / BSC are observable to passive observers. Lower bridge throughput means fewer correlation surfaces but no diversification of trust assumptions.
Under CRQC, every historical signature is forgeable, every recursive proof's soundness premise breaks, and any zkApp that used Pickles to hide application-state loses its hiding property retroactively. For a chain whose distinctive feature is recursive-proof-as-history-substitute, the retroactive-deanon surface is structural, not incidental.
L1 profile uses 4 sub-scores for Dim 3; this entry not scored.
4 Migration Architecture weight 10% 51 / 100
Mina's hard-fork process is documented (MIP-based on-chain voting; Berkeley 2024-06-04 and Mesa 2026 demonstrate execution), but algorithm switching at the proof-system layer is structurally expensive. Pickles, Kimchi, and the entire o1js stack are wired to the Pasta cycle. A switch to FRI-based PQ-safe proof system would replace the proving stack and likely on-chain verifier circuits.
zkApp accounts implement programmable authorization (custom verification keys, in-circuit logic for spending conditions) via o1js, a form of account-contract-style flexibility. The underlying signing primitive available to zkApps is still Schnorr/Pallas; o1js exposes Poseidon, Blake2b, ECDSA on secp256k1, Keccak, but not ML-DSA, SLH-DSA, or Falcon precompiles.
Mina has executed two coordinated mainnet upgrades in the last 3 years: Berkeley (2024-06-04, MIPs 1/3/4) and the upcoming Mesa upgrade (MIPs 6-9, scheduled 2026, on-chain vote unanimous in December 2025; Mesa testnet launched 2025-11-29). On-chain MIP voting is the documented governance mechanism.
Hybrid PQ deployment at the proof-system layer would require running a FRI-based system in parallel with Kimchi/Pickles; architecturally feasible but no spec, no announcement. Mina's small primitive surface and modular proof-system code make hybrid theoretically more tractable than monolithic stacks, but theoretical feasibility is not deployment readiness.
Mina uses no stateful hash signatures (XMSS, LMS, leanXMSS). Stateless schemes only. Full credit by rubric default.
N/A, Mina's Ouroboros Samasika consensus uses VRF-based slot-leader selection. Block production is single-leader-per-slot, not committee-attested with aggregated signatures. No BLS aggregation, no committee attestation set, no signature-aggregation path in the consensus protocol. Per v3.1 rubric, 4f is N/A for chains using non-aggregating signatures at consensus.
5 Deployment Execution weight 22% 12 / 100
Zero PQC primitives signing any byte on Mina mainnet. The Mesa upgrade (scheduled 2026, MIPs 6-9) addresses block slot time, on-chain state limits, events/actions limits, and zkApp account-update limits, explicitly performance/capacity, no cryptographic primitive changes.
MinaProtocol/mina (OCaml/Rust node) and o1-labs/proof-systems contain no ML-DSA / ML-KEM / SLH-DSA / Falcon / FRI / lattice / hash-based-signature implementation in any merged production path.
Block producers register Schnorr/Pallas keys for VRF and signing. No PQ key registration is supported by the protocol or used by validators.
Voided to 0 per v3.1.0 (5a = 0). Mesa MIPs 6-9 are entirely non-cryptographic. The 2025 recap and 2026 Mesa documentation contain no PQ section.
Mina is not engaged in announcement-to-shipped. No PQ announcements have been made; no PQ has been shipped. Score below 15 reflects residual narrative risk: the 'succinct blockchain' framing is occasionally externally conflated with quantum resistance (ZK ≠ PQ; Pasta-IPA proofs are succinct AND classically secure AND post-quantum-broken). The foundation itself is silent rather than overclaiming.
No PQ-signature footprint has been measured because none is deployed. Score is 0 by absence of artifact.
6 Supply Chain Vendor Readiness weight 22% 6 / 100
Top-3: Auro Wallet (Least Authority audit 2021; OtterSec audit 2024 for Fungible Token Standard support), Pallad (OtterSec audit; mainnet beta as of Pallad 0.6), Clorio Wallet. None has published a PQC roadmap. Audits cover application-layer correctness, not PQ-readiness.
Top-3: lambdaclass mina_bridge via Aligned Layer (research/devnet status, not production), =nil; Foundation Proof Market, wrapped-MINA representations on Ethereum / BSC via centralized custodians. No major general-purpose bridge (LayerZero, Wormhole, Axelar, CCIP) operates Mina endpoints. No PQC roadmap published by any bridge integrator.
Top-3: Coinbase (exchange + Coinbase Cloud non-custodial infra), Fireblocks (limited MINA support), BitGo (1,550+ assets coverage). Institutional MINA custody coverage exists but specific PQC roadmaps for MINA-handling wallets/keys are not published by any of the top three.
Top-3: o1Labs nodes (canonical infra), Block-producer GraphQL endpoints (community-operated), Aligned Layer (proof-aggregation infra for Mina→Ethereum). No HSM / TEE / RPC PQC posture published for Mina validator/prover infrastructure.
7 Governance & Coordination weight 8% 36 / 100
Mina uses Ouroboros Samasika PoS with permissionless block production (no minimum stake, no slashing, unbounded participant count). Active block-producer count is variable; practical stake-weight concentration is not separately published as a Nakamoto-coefficient metric. Single OCaml/Rust client implementation across the network, single-client risk is the dominant governance-side concern.
Two coordinated mainnet upgrades in the last 3 years (Berkeley 2024-06-04; Mesa scheduled 2026 with unanimous on-chain MIP approval December 2025). Both executed under non-adversarial conditions. No demonstrated upgrade under crypto-deadline pressure.
o1Labs is the technical team behind Mina (Mina Foundation transferred protocol responsibility to o1Labs in 2025; Mina Foundation scaled down). o1Labs publishes a research-grade cryptography output. No PQ working group is announced, no PQ lead is named in foundation communications, no PQ mandate is published.
Mina has handled standard protocol-level issues (Berkeley delays, hard-fork rescheduling) but has no precedent for coordinated cryptographic change under active attacker pressure or under hard regulatory deadline. PQ-specific coordination precedent: zero.
No canary, honeypot, rate-limiter, or cryptographic tripwire embedded in Mina consensus or application layer.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y midpoint ~17 years (2043), Crisis Zone (vs Z10 2030); Outside risk window (vs Z25 2035)
Z-compliance
Outside compliance window (X+Y > 2035 against NIST 2030 deprecation / 2035 disallowance)
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
Community / secondary sources occasionally conflate Mina's 22KB recursive-proof design with quantum resistance. The foundation itself does not make this claim; Pasta-IPA Halo2 is succinct AND classically-secure AND post-quantum-broken (IPA security reduces to discrete-log on Pallas/Vesta).
Mina/o1Labs uses the Halo2-family-IPA flavor (Pasta-cycle, no pairings, no trusted setup). The PSE/Ethereum Halo2-KZG fork uses pairings. v2 LayerQu materials and some external materials conflated these. This card uses the IPA designation throughout.
Some external commentary frames Mesa as a major cryptographic upgrade; the published MIP set (6–9) is purely throughput/capacity. No primitive change.
Delta-QRI under alternative weighting
Under heavier deployment-execution-emphasis alternative-weighting: -3 to -5 points (Mina's Dim 5 = 12 is the binding factor; any rubric weighting Dim 5 above 22% pushes QRI lower).
Announcement-to-shipped ratio
Announced: 0. Shipped: 0. Ratio: 0.
Tag: none, Mina is silent, not over-claiming
Peers in the L1 profile
9 chains closest to Mina by Stage then QRI.