--- title: Is Mina Protocol quantum-safe? chain: Mina Protocol ticker: MINA hardy_score: 8.5 rank: 67 of 80 tier: "5: Exposed" url: "https://hardyindex.com/chains/mina" updated: 2026-10-22 reviewed: 2026-11-13 methodology_version: 1.8 --- # Is Mina Protocol quantum-safe? **Hardy Score 8.5 / 100. Rank 67 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.** No. Mina accounts sign with a Schnorr signature scheme over Pallas, one of the two Pasta elliptic curves, and a Mina address is the account's public key, the B62 string that the documentation says can be thought of as an address. Everything else that secures the chain is built on the same curves: block producers are elected by a verifiable random function computed on the Pallas group, and the Kimchi proof system and Pickles recursion that let anyone verify the whole chain from a small proof work over Pallas and Vesta. A sufficiently large quantum computer running Shor's algorithm would break the signatures, and the proving system rests on the same discrete-logarithm mathematics. Being a zero-knowledge chain does not make Mina quantum-resistant. We found no post-quantum position from o1Labs, the Mina Foundation or the Mina Improvement Proposal process: none of the MIPs mentions post-quantum cryptography, and the two threads on the Mina forum that raise it, from 2022, drew replies and no plan. > This is a security-readiness assessment, not investment advice. ## Summary Accounts sign with Schnorr signatures over the Pallas curve behind addresses that are the public key, the recursive proofs that keep the chain succinct rest on the same Pasta curves, and no post-quantum proposal, plan or research programme for Mina could be found. ## Where we are making a judgement call Three judgement calls carry this profile. The first is exposure. The rubric's bottom band covers chains where keys are exposed for effectively all accounts, and an address that is the key meets it on structure alone. Mina is scored 2 on that reading, as Solana, Kaspa, Stellar, Algorand, Hedera, Polkadot and Bittensor are. A reader who holds that an unmeasured share belongs at the floor of the band above would score Mina 3, a gain of 1.0 point. The second is migration. Mina accounts can set permissions so that sending funds requires a zero-knowledge proof rather than a signature, which moves authority away from the key. We do not credit it as a migration mechanism, because the proofs that would take over are Kimchi proofs over the same elliptic curves and a quantum adversary could forge them too. A reader who counts programmable authorisation as a route, as the TON profile counts wallets that are contracts, would score migration 3 and add 1.5 points. Migration also sits below Kaia's 3, where an account update replaces the key behind an address in place, because on Mina the original key never fully loses authority: o1Labs' permissions documentation says setVerificationKey cannot be set to impossible or proof permanently, and its version-limited settings let a signature change the verification key again after a protocol upgrade. The third concerns scope under v1.8. The proving system is not a signature, but it is what finalises Mina's chain and authorises zkApp spends, so it is read here as part of what protects funds, as Zcash's Halo 2 is; either way it is classical and no score turns on it. Our finding is that we could not locate a published post-quantum position, not that we have confirmed none exists, and a primary source is the quickest way to correct it. ## Score breakdown | # | Dimension | Score | Weight | Contribution | |---:|---|---:|---:|---:| | 1 | Signature scheme | 0/10 | 30% | 0.0 | | 2 | Deployment stage | 1/10 | 25% | 2.5 | | 3 | NIST alignment | 0/10 | 15% | 0.0 | | 4 | Migration path | 2/10 | 15% | 3.0 | | 5 | Exposure | 2/10 | 10% | 2.0 | | 6 | Verification | 2/10 | 5% | 1.0 | | | **Hardy Score** | | | **8.5** | ### 1. Signature scheme: 0/10 Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on. Mina's signature specification defines key-prefixed Schnorr signatures over the Pallas curve, adapted from BIP 340, and every transaction and account update authorised by signature uses it. Account permissions can require a zero-knowledge proof instead, but those proofs are Kimchi proofs over the same Pasta curves. Nothing post-quantum protects MINA or any asset on Mina today. Source: https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md ### 2. Deployment stage: 1/10 Anchor band 1: Tier 5: Exposed. Tier 5: Exposed. The signatures and proofs protecting funds and finalising blocks are quantum-vulnerable, and no Mina Improvement Proposal, o1Labs or Mina Foundation publication, or research programme on post-quantum signatures for Mina was found. The forum threads that raise the subject contain opinion and no plan. Source: https://github.com/MinaProtocol/MIPs ### 3. NIST alignment: 0/10 Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis. No post-quantum scheme has been named for Mina's account signatures, its block-producer keys or its proving system, so there is nothing to assess against a NIST standard. Placement in the band: The floor of the band rather than a 1 or a 2: nobody with authority over Mina has named a post-quantum scheme, even as an example, so there is no choice to align with a standard. Source: https://github.com/MinaProtocol/MIPs ### 4. Migration path: 2/10 Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds. No migration plan or published position exists. Mina has a record of coordinated protocol upgrades through its MIP process: the Berkeley upgrade of June 2024 brought the Kimchi proof system and zkApps, and the Mesa upgrade, which activated on mainnet on 3 September 2026, carried four more MIPs and added automation for future hard forks. An account is identified by its public key, so its key cannot be replaced in place, and nothing addresses accounts whose keys are already public. Placement in the band: The top of the band rather than a 0 or a 1: two hard forks since June 2024, carrying MIPs voted on by the community and now backed by hard-fork automation, are the route a new signature scheme and proving system would need. Not a 3, because nobody with authority over Mina has acknowledged the quantum problem in public, let alone described a route for holders. Source: https://github.com/MinaProtocol/mina/releases/tag/4.0.0-mainnet-mesa ### 5. Exposure: 2/10 Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses. A Mina account is tracked by its public key, and Mina's glossary says public keys, which start with B62, can be thought of as addresses. The key is therefore readable from the address alone, before the account has ever signed, so every account's key can be collected today. zkApp accounts are identified by a public key in the same way. Placement in the band: The top of the band rather than a 0 or a 1: Mina meets this band on its structural limb, the address being the key itself, but no measured share of at-risk supply has been published. Not a 3, because no account on Mina has a hidden key at all. Source: https://docs.minaprotocol.com/glossary ### 6. Verification: 2/10 Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing. No post-quantum component exists for Mina: no code, specification or testnet implementation was found in the node, the proof-systems library or the MIPs. Both are open source, but under v1.8 the openness of classical code earns nothing on this dimension. Placement in the band: The top of the band rather than a 0 or a 1: there is nothing post-quantum to verify, but Mina is not marketed as quantum-safe, so its position does not rest on marketing. Source: https://github.com/MinaProtocol/mina ## Nearest chains in the ranking The chains Mina sits among, out of 80 rated. The last column is the gap in Hardy points from Mina. | Rank | Chain | Tier | Hardy | vs MINA | |---:|---|---|---:|---:| | 63 | [Gnosis Chain](https://hardyindex.com/chains/gnosis) | 5: Exposed | 8.5 | level | | 64 | [Injective](https://hardyindex.com/chains/injective) | 5: Exposed | 8.5 | level | | 65 | [KCC (KuCoin Community Chain)](https://hardyindex.com/chains/kcc) | 5: Exposed | 8.5 | level | | 66 | [Kite](https://hardyindex.com/chains/kite) | 5: Exposed | 8.5 | level | | 67 | **Mina Protocol** | 5: Exposed | 8.5 | this chain | | 68 | [MultiversX](https://hardyindex.com/chains/multiversx) | 5: Exposed | 8.5 | level | | 69 | [Polygon PoS](https://hardyindex.com/chains/polygon-pos) | 5: Exposed | 8.5 | level | | 70 | [Provenance Blockchain](https://hardyindex.com/chains/provenance) | 5: Exposed | 8.5 | level | | 71 | [Theta Network](https://hardyindex.com/chains/theta) | 5: Exposed | 8.5 | level | ## Signature scheme - **On mainnet today:** Schnorr signatures over the Pallas curve for accounts; a Pallas-based VRF for block-producer election; Kimchi proofs with Pickles recursion over the Pasta curves for the succinct chain and zkApps - **Post-quantum scheme:** None. No post-quantum scheme has been proposed, selected or tested for Mina. - **NIST standard:** None adopted. - **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found. ## Cryptography in use - **Account signatures:** [Mina Schnorr signatures on Pallas](https://hardyindex.com/algorithms/schnorr-pallas.md). Mainnet, default. Key-prefixed Schnorr signatures over the Pallas curve, adapted from BIP 340, authorise every Mina transaction and account update. Source (specification or proposal): https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md. ## Roadmap - **2 January 2022** (shipped): A thread titled "Post Quantum Security" opens on the Mina forum asking whether the developers could make room for post-quantum work. The replies argue it is not yet needed, and no plan follows. Source: https://forums.minaprotocol.com/t/post-quantum-security/5214 - **No published position** (proposed): No post-quantum Mina Improvement Proposal, roadmap, research programme or testnet implementation for Mina's signatures or proving system was found from o1Labs, the Mina Foundation or the MIP process at the time of writing. Source: https://github.com/MinaProtocol/MIPs ## If holders never migrate **No stated policy.** Neither o1Labs, the Mina Foundation nor the MIP process has said anything about post-quantum migration, so nothing has been said about accounts that never move to post-quantum keys. As of 22 October 2026. ## Exposure Mina's exposure is structural. Accounts are tracked by public key and the B62 public key is the address, not a hash of it, so there is no equivalent of an unspent hashed address whose key stays private until first use: every account publishes its key when the address exists, and an adversary collecting keys today needs only a list of addresses. zkApp accounts are no different, since they too are identified by a public key. Mina's succinctness changes none of this. Recursive proofs let a node verify the chain without storing it, but accounts are still identified by public key, and the proofs themselves rest on the same Pasta curves. No measurement of at-risk supply has been published for Mina. ## Frequently asked questions ### Is Mina Protocol quantum-safe? No. Mina accounts sign with a Schnorr signature scheme over Pallas, one of the two Pasta elliptic curves, and a Mina address is the account's public key, the B62 string that the documentation says can be thought of as an address. Everything else that secures the chain is built on the same curves: block producers are elected by a verifiable random function computed on the Pallas group, and the Kimchi proof system and Pickles recursion that let anyone verify the whole chain from a small proof work over Pallas and Vesta. A sufficiently large quantum computer running Shor's algorithm would break the signatures, and the proving system rests on the same discrete-logarithm mathematics. Being a zero-knowledge chain does not make Mina quantum-resistant. We found no post-quantum position from o1Labs, the Mina Foundation or the Mina Improvement Proposal process: none of the MIPs mentions post-quantum cryptography, and the two threads on the Mina forum that raise it, from 2022, drew replies and no plan. ### Is Mina quantum-safe? No. Mina accounts sign with Schnorr signatures over the Pallas elliptic curve, and the recursive proofs that keep the chain succinct are built over the same Pasta curves. A sufficiently large quantum computer would break the signatures, and no post-quantum plan for Mina has been published. ### Do zero-knowledge proofs make Mina quantum-resistant? No. Zero-knowledge proofs let Mina verify its whole history from a small proof and let zkApps prove facts without revealing data. Whether those proofs survive a quantum computer depends on the mathematics underneath, and Kimchi and Pickles work over the Pallas and Vesta elliptic curves, which rest on the discrete-logarithm problem that Shor's algorithm solves. ### Are MINA holders' public keys already exposed? Yes, for every account. A Mina address is the B62 encoding of the account's public key, so the key is readable from the address whether or not the account has ever sent a transaction. Those keys can be recorded now and attacked later. ### What would move Mina up the index? A Mina Improvement Proposal, or a public research programme from o1Labs or the Mina Foundation, on post-quantum signatures or a post-quantum proving system for Mina would meet the Tier 4 floor. A published plan from the chain's own authority, or an adopted MIP, naming the scheme to be used would meet Tier 3. ## What this rating means if you hold Mina Plain-language guidance from the same publication, with no product recommendation attached. - [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md) - [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md) - [All guides](https://hardyindex.com/guides.md) ## Sources 1. [Mina Schnorr Signatures (docs/specs/signatures/description.md)](https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md): Mina Protocol (GitHub) (primary, checked 22 October 2026) 2. [Mina node client](https://github.com/MinaProtocol/mina): Mina Protocol (GitHub) (primary, checked 22 October 2026) 3. [Consensus VRF (src/lib/consensus/vrf/consensus_vrf.ml)](https://github.com/MinaProtocol/mina/blob/compatible/src/lib/consensus/vrf/consensus_vrf.ml): Mina Protocol (GitHub) (primary, checked 22 October 2026) 4. [Pickles specification](https://github.com/o1-labs/proof-systems/blob/master/book/docs/specs/pickles.md): o1Labs (GitHub) (primary, checked 22 October 2026) 5. [Pasta curves specification](https://github.com/o1-labs/proof-systems/blob/master/book/docs/specs/pasta.md): o1Labs (GitHub) (primary, checked 22 October 2026) 6. [Glossary](https://docs.minaprotocol.com/glossary): Mina Protocol documentation (primary, checked 22 October 2026) 7. [Permissions](https://docs.o1labs.org/o1js/zkapps/permissions): o1Labs documentation (primary, checked 22 October 2026) 8. [Mina Improvement Proposals](https://github.com/MinaProtocol/MIPs): Mina Protocol (GitHub) (primary, checked 22 October 2026) 9. [MIP-3: Kimchi, a new proof system](https://github.com/MinaProtocol/MIPs/blob/main/MIPS/mip-0003-kimchi.md): Mina Protocol (GitHub) (primary, checked 22 October 2026) 10. [Release 3.0.0 (Berkeley)](https://github.com/MinaProtocol/mina/releases/tag/3.0.0): Mina Protocol (GitHub) (primary, checked 22 October 2026) 11. [Release 4.0.0-mainnet-mesa](https://github.com/MinaProtocol/mina/releases/tag/4.0.0-mainnet-mesa): Mina Protocol (GitHub) (primary, checked 22 October 2026) 12. [Mesa fork schedule](https://docs.minaprotocol.com/network-upgrades/mesa/fork-schedule): Mina Protocol documentation (primary, checked 22 October 2026) 13. [Post Quantum Security](https://forums.minaprotocol.com/t/post-quantum-security/5214): Mina Protocol forum (primary, checked 22 October 2026) 14. [SNARKs - STARKs Quantum computers](https://forums.minaprotocol.com/t/snarks-starks-quantum-computers/5762): Mina Protocol forum (primary, checked 22 October 2026) ## How to cite this rating A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too. The Hardy Index (2026). Mina Protocol: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/mina ```bibtex @misc{hardyindex_mina_2026, author = {{The Hardy Index}}, title = {Mina Protocol: quantum readiness assessment}, year = {2026}, howpublished = {\url{https://hardyindex.com/chains/mina}}, note = {Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8}, urldate = {2026-11-13} } ``` --- Methodology: https://hardyindex.com/methodology (v1.8). Cite as: The Hardy Index, "Mina Protocol", https://hardyindex.com/chains/mina, as of 13 November 2026.