Mina Protocol

Is Mina Protocol quantum-safe?

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.

At a glance

Cryptography in use

• Account signatures Mina Schnorr signatures on Pallas Mainnet, default Key-prefixed Schnorr signatures over the Pallas curve, adapted from BIP 340, authorise every Mina transaction and account update. Specification or proposal

A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.

Score breakdown

How it compares

Roadmap

1. 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

2. 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

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. Published beside the score, not in it. Every chain's stance is compared on the commitments page.

Exposure

Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.

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.

Questions

Sources

1. Mina Schnorr Signatures (docs/specs/signatures/description.md) Mina Protocol (GitHub) · primary · checked 22 October 2026
2. Mina node client Mina Protocol (GitHub) · primary · checked 22 October 2026
3. Consensus VRF (src/lib/consensus/vrf/consensus_vrf.ml) Mina Protocol (GitHub) · primary · checked 22 October 2026
4. Pickles specification o1Labs (GitHub) · primary · checked 22 October 2026
5. Pasta curves specification o1Labs (GitHub) · primary · checked 22 October 2026
6. Glossary Mina Protocol documentation · primary · checked 22 October 2026
7. Permissions o1Labs documentation · primary · checked 22 October 2026
8. Mina Improvement Proposals Mina Protocol (GitHub) · primary · checked 22 October 2026
9. MIP-3: Kimchi, a new proof system Mina Protocol (GitHub) · primary · checked 22 October 2026
10. Release 3.0.0 (Berkeley) Mina Protocol (GitHub) · primary · checked 22 October 2026
11. Release 4.0.0-mainnet-mesa Mina Protocol (GitHub) · primary · checked 22 October 2026
12. Mesa fork schedule Mina Protocol documentation · primary · checked 22 October 2026
13. Post Quantum Security Mina Protocol forum · primary · checked 22 October 2026
14. SNARKs - STARKs Quantum computers Mina Protocol forum · primary · checked 22 October 2026

@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}
}