Blockchain Quantum Readiness Index / Starknet
L2 · Cairo
Starknet
A Falcon post-quantum account has sent a real mainnet transfer, though StarkWare labels it experimental and unaudited. Proof verification is hash-based but also relies on elliptic-curve components (KZG checks, the Pedersen state hash), and bridge messaging uses quantum-vulnerable elliptic-curve syscalls. A 12-member security council can upgrade core contracts immediately in emergencies; StarkWare published a three-phase post-quantum roadmap in June 2026. In a non-binding vote that closed on 22 October 2026, 93.52% backed researching a move to an independent post-quantum L1; the vote starts research only, and Starknet still runs as an Ethereum rollup.
Last reviewed 2026-10-19
Is Starknet quantum safe?
Not yet. Starknet is at Stage 4 (Live option) in LimeChain's Blockchain Quantum Readiness Index, with a progress score of 22/100. Users can already hold funds under a post-quantum key on mainnet, but it does not yet meet the escape-hatch bar: an approved standard, a current audit and post-quantum consensus work. Still exposed or unproven: proof system, bridges & messaging, admin & upgrade keys.
What Starknet needs for Stage 5: Escape hatch
- Stage 5 needs U live with an approved mechanism and PQ-only funds at rest (is: live-experimental, mechanism: FN-DSA, hold: pq)
- Stage 5 needs a valid audit of the deployed PQ code (not claimed)
- Stage 5 needs C at least in-dev (is: planned)
- Stage 5 needs P not exposed/unknown (is: exposed)
- Stage 5 needs A live, or an exit window of at least 7 days before upgrades
- Stage 5 needs its settlement layer ethereum to reach Stage 5 (is: Stage 3)
Caps and adjustments
- U: FN-DSA is a standardization candidate, not yet approved -> max 8 points, cannot pass stage gates
- P: mechanism STARK is vulnerable (component KZG is vulnerable: Shor's algorithm breaks discrete logarithms in pairing groups. Forged openings can make a verifier accept wrong blob data.) -> treated as exposed
- cap 40: users cannot hold and spend funds under a production PQ mechanism on mainnet
- cap 60: consensus PQ not even on testnet
Rosette slices
| Slice | State | Points | Weight | Reason & evidence |
|---|---|---|---|---|
| U User keys | Live (experimental) non-standard FN-DSA Falcon-512 lattice parameters; the OpenZeppelin account variants swap hash-to-point for BLAKE2s or Poseidon, and which variant the mainnet demo uses is not published ⚠ Floating-point signing makes constant-time, side-channel-safe hardware wallets and secure elements harder to build. Integer-only verification leaves on-chain verification unaffected. At rest: PQ-protected at rest Account-level: the OpenZeppelin Falcon-512 account contracts (pinned commit bece5c0) store a fixed Falcon public key, validate every transaction with Falcon and contain no replace_class/upgrade or key-rotation entrypoint, so once an account runs this class no ECC key can move, re-key or upgrade it (an existing ECC account can switch to it in place, as the mainnet demo did). Caveats: StarkWare and OpenZeppelin label it experimental and unaudited; system-level, the ECC Security Council can upgrade Starknet core contracts immediately in an emergency (captured by slice A and the L2 gates, not by hold). |
6/10 | 25 | A Falcon-512 smart-contract account has sent a real mainnet transfer; StarkWare labels it experimental, unaudited research, so audited_pq_impl stays false. The OpenZeppelin PQ account contracts have no class-replacement/upgrade path (checked at commit bece5c0, 2026-10-12), so no ECC key can swap the account code. |
| C Consensus | Planned | 2/10 | 20 | Sequencer/consensus signatures remain elliptic-curve; the roadmap lists PQ consensus signatures such as Falcon-512 without a shipped date. Sources 3 |
| P Proof system | Exposed vulnerable STARK STARK/FRI (hash-based) claimed “live-pq” without valid evidence |
0/10 | 10 | STARK proofs are hash-based, but the Ethereum verifier also checks the state-diff blobs with KZG proofs through the point-evaluation precompile (Starknet.sol verifyKzgProofs), and the contracts state trie uses the elliptic-curve Pedersen hash. Both are in the verification path, so the slice is only as strong as KZG and Pedersen. |
| B Bridges & messaging | Exposed | 0/10 | 15 | StarkWare states the Cairo VM's secp256k1/r1 syscalls behind L1-to-L2 messaging and the Ethereum bridge are quantum-vulnerable and can only be removed after Ethereum's own migration. Sources 3 |
| A Admin & upgrade keys | Exposed | 0/10 | 15 | The Security Council is a 12-member ECC multisig controlling Starknet's core contracts on Starknet and Ethereum, able to respond to a live incident 'within minutes'; per SNIP-25 regular upgrades have a 7-day delay with >50% approval, but emergency actions need only 75% (9/12) and take effect immediately. |
| M Migration & recovery | Planned | 2/10 | 15 | Accounts can switch validation logic in place keeping the same address, and roadmap phase 2 targets legacy contracts, but StarkWare's register says legacy storage migration tooling is 'research announced' with no public specification or released toolkit. |
Stage gates
| Requirement | Status | Details & evidence |
|---|---|---|
| Current audit of the deployed PQ signing code (Stage 5) | Not met | not claimed |
| Exit window of at least 7 days before upgrades (Stage 5, L2s with ECC admin keys) | Not met | not claimed |
| Admin timelock of at least 30 days with a PQ override (Stage 6, alternative to PQ admin keys) | Not met | not claimed |
| Ratified migration plan with an activation date (Stage 6) | Not met | not claimed |
| New accounts PQ or hybrid by default (Stage 6) | Not met | not claimed |
| ECC sunset enforced (Stage 7) | Not met | not claimed |
PQ adoption published, not scored
No published adoption numbers were found yet. Having PQ accounts does not mean people move to them. This tracks the share of value and accounts that actually moved, over time.
Measured exposure
No on-chain probe run yet. Bitcoin, Solana, Cosmos and Substrate probes are planned.
Evidence and sources (11)
Every non-zero rating above cites at least one of these public sources.
- starknet.io/blog/quantum-resistance/
- quantum.starkware.co/migration-register
- starkware.co/blog/the-architecture-advantage-starknets-quantu…
- github.com/OpenZeppelin/cairo-pq-verifiers/pull/2
- raw.githubusercontent.com/OpenZeppelin/cairo-pq-verifiers/bec…
- raw.githubusercontent.com/OpenZeppelin/cairo-pq-verifiers/bec…
- raw.githubusercontent.com/OpenZeppelin/cairo-pq-verifiers/bec…
- docs.starknet.io/learn/protocol/security-council.md
- github.com/starkware-libs/cairo-lang/blob/cf9bf972bede402a125…
- docs.starknet.io/learn/protocol/state.md
- github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-25.md
Source: chains/starknet.json. Reproduce: python3 score.py chains/starknet.json
Building on Starknet?
LimeChain helps teams plan their post-quantum migration: what is exposed, what to change first, and the engineering to get there.
Talk to usOpen, repeatable scoring. Non-zero ratings need public evidence; missing evidence means unknown. Methodology v0.4 · mechanism registry 2026-10-13.