{
  "id": "starknet",
  "name": "Starknet",
  "type": "Validity rollup (L2)",
  "reviewed": "2026-07-03",
  "summary": "Starknet's proving is post-quantum secure — STARKs are hash-based, transparent, and verified recursively on Ethereum — but its accounts, sequencer consensus, settlement authorization, data availability, oracles and networking all still rely on Shor-breakable elliptic-curve crypto. Deep-research-verified against StarkWare primary sources (June 2026). A textbook case of the core message: a quantum-safe proof system does not by itself make a quantum-safe chain.",
  "links": {
    "Website": "https://www.starknet.io",
    "Docs": "https://docs.starknet.io",
    "GitHub": "https://github.com/starkware-libs"
  },
  "assessment": {
    "1.1": { "verdict": "fail", "scheme": "Stark-curve ECDSA (default)", "why": "Production accounts (e.g. Argent/Ready) sign with the Stark curve by default and support only Shor-breakable EC schemes (Stark-curve, secp256k1, secp256r1, WebAuthn); no post-quantum scheme ships by default. Fails the election route at E2: the only live PQ option, Falcon-512 (s2morrow), uses a scheme whose NIST standard (FIPS 206 / FN-DSA) is not yet finalized; it is also an unaudited demo (E3) with no production wallet integration (E4), and OpenZeppelin's PQ account is still in development. StarkWare's July 2026 quantum-readiness roadmap keeps account migration opt-in.", "sources": ["https://github.com/argentlabs/argent-contracts-starknet/blob/main/docs/signers_and_signatures.md", "https://www.starknet.io/en/content/how-starknet-is-revolutionizing-crypto-signing", "https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/"] },
    "1.2": { "verdict": "fail", "scheme": "Stark-curve / secp256 keys", "why": "Stored keys are the same breakable EC keys; PQ custody only follows once an account adopts a PQ scheme, which none do by default." },
    "1.3": { "verdict": "fail", "scheme": "Classical threshold", "why": "Multi-party signing still splits classical keys; PQ threshold signing is research-stage." },
    "1.4": { "verdict": "fail", "scheme": "Native AA (classical verifiers only)", "why": "Native account abstraction is Starknet's key structural advantage — a PQ-signature verifier can be added per-account with no hard fork, and Falcon-512 has been demonstrated (s2morrow). But no production account implements a PQ verifier by default, and the demonstrated option fails the election route at E2 (FIPS 206 / FN-DSA not yet finalized), E3 (unaudited demo), and E4 (no generally available wallet offers it), so it fails on both routes. It flips the day an audited, wallet-accessible account contract using a finalized NIST scheme ships on mainnet.", "sources": ["https://docs.starknet.io/learn/protocol/accounts", "https://github.com/argentlabs/argent-contracts-starknet/blob/main/docs/signers_and_signatures.md", "https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/"] },
    "1.5": { "verdict": "fail", "scheme": "Session keys, secp256r1 passkeys", "why": "Session keys and WebAuthn passkeys rely on breakable curves (Stark-curve, secp256r1), both supported but neither post-quantum." },
    "1.6": { "verdict": "fail", "scheme": "Starknet.id", "why": "Naming/identity inherits the controlling account's signature, which is breakable until accounts move to PQ." },
    "1.7": { "verdict": "fail", "scheme": "Account-signed votes", "why": "Governance is authorized by account signatures, which are breakable today." },
    "2.1": { "verdict": "fail", "scheme": "In-contract ECDSA", "why": "Contracts verify signatures in-contract with elliptic-curve ECDSA (e.g. verify_eth_signature over secp256k1); there is no post-quantum signature precompile.", "sources": ["https://starknet-by-example.voyager.online/advanced-concepts/signature_verification/"] },
    "2.2": { "verdict": "na", "scheme": "", "why": "Verification at the protocol core is STARK-based — even the L1 settlement contract validates STARK proofs, not pairing-based SNARKs — so there are no pairing verifier contracts to break.", "sources": ["https://docs.starknet.io/architecture-and-concepts/solidity-verifier/"] },
    "2.3": { "verdict": "fail", "scheme": "Operator-signed feeds (Pragma)", "why": "On-chain oracle feeds (e.g. Pragma) authenticate data with classical signatures.", "sources": ["https://docs.pragma.build/starknet/introduction"] },
    "2.4": { "verdict": "fail", "scheme": "EC-based VRF (Pragma)", "why": "On-chain verifiable randomness (e.g. Pragma VRF) is elliptic-curve based; PQ VRFs are research-stage.", "sources": ["https://blog.pragma.build/introducing-the-verifiable-random-function-vrf-in-cairo-1/"] },
    "2.5": { "verdict": "na", "scheme": "", "why": "Starknet does not rely on a verifiable delay function." },
    "3.1": { "verdict": "fail", "scheme": "Tendermint sequencers", "why": "Since v0.14.0 (Grinta), block ordering is run by a live Tendermint consensus across three sequencers (currently all StarkWare-operated) that sign with classical keys.", "sources": ["https://www.starknet.io/blog/starknet-grinta-the-architecture-of-a-more-decentralized-future/"] },
    "3.2": { "verdict": "pass", "scheme": "STARK / FRI", "why": "Proving uses STARKs (hash-based, FRI), recursively verified and validated by an L1 Solidity verifier — post-quantum secure. This is Starknet's central quantum strength.", "sources": ["https://docs.starknet.io/architecture-and-concepts/solidity-verifier/"] },
    "3.3": { "verdict": "pass", "scheme": "Transparent (FRI)", "why": "STARKs are transparent — there is no trusted-setup secret for a quantum computer to recover.", "sources": ["https://docs.starknet.io/architecture-and-concepts/solidity-verifier/"] },
    "3.4": { "verdict": "fail", "scheme": "EIP-4844 KZG blobs (default)", "why": "Since v0.13.1 the default is to post state diffs to Ethereum as EIP-4844 blobs, whose KZG commitments are pairing-based and Shor-breakable (calldata is only a fallback). Volition can keep data off-chain (L2/validium) per variable, but the rollup default uses KZG blobs.", "sources": ["https://docs.starknet.io/learn/protocol/data-availability", "https://www.starknet.io/blog/volition-on-starknet/"] },
    "3.5": { "verdict": "fail", "scheme": "Pedersen trie (Poseidon top-commit)", "why": "The state is a binary Merkle-Patricia trie built on the Pedersen hash, which is elliptic-curve-based and not Shor-resistant; only the top-level commitment combining the trie roots uses hash-based Poseidon. The migration to Poseidon is incomplete.", "sources": ["https://docs.starknet.io/architecture/state/"] },
    "3.6": { "verdict": "pass", "scheme": "Cairo VM", "why": "The Cairo VM carries no cryptography of its own; signature and proof checks live in other components." },
    "4.1": { "verdict": "fail", "scheme": "Tendermint consensus (classical)", "why": "As of v0.14.0 (Grinta, live on mainnet) Starknet runs Tendermint consensus across three sequencers (1/2 threshold, currently all StarkWare-operated) that sign blocks with classical keys — a Shor-breakable consensus-signature set. Ultimate finality still derives from L1 STARK verification, but the consensus signing layer is now a real, breakable surface.", "sources": ["https://www.starknet.io/blog/how-starknets-q3-paved-the-way-for-bitcoin-decentralization-and-the-future-of-crypto/", "https://www.starknet.io/blog/starknet-grinta-the-architecture-of-a-more-decentralized-future/"] },
    "4.2": { "verdict": "pass", "scheme": "STARK-verified light client", "why": "Light clients (e.g. Beerus) verify Starknet via STARK proofs rather than a BLS sync committee, so header trust is hash-based and post-quantum safe.", "sources": ["https://github.com/eigerco/beerus"] },
    "4.3": { "verdict": "fail", "scheme": "Ethereum ECDSA + KZG DA", "why": "On L1 the STARK proof verification itself is hash-based and post-quantum safe, but state updates are authorized by an operator's Ethereum ECDSA transaction and accompanied by KZG-blob data availability — both Shor-breakable — so the settlement path as a whole is not quantum-safe.", "sources": ["https://docs.starknet.io/architecture-and-concepts/solidity-verifier/", "https://docs.starknet.io/learn/protocol/messaging"] },
    "4.4": { "verdict": "fail", "scheme": "StarkGate (canonical bridge)", "why": "Scored against the canonical bridge, StarkGate: withdrawals are authorized on its L1 bridge contract by Ethereum ECDSA, which Shor breaks. (Third-party bridges are scored against their operators, not the chain.)" },
    "4.5": { "verdict": "na", "scheme": "", "why": "Starknet does not use restaking / AVS attestations in its core protocol." },
    "4.6": { "verdict": "na", "scheme": "", "why": "Payment channels / HTLCs are not part of the core protocol." },
    "4.7": { "verdict": "na", "scheme": "", "why": "Block building is handled by the sequencer consensus set; there is no separate PBS / MEV-Boost relay market." },
    "5.1": { "verdict": "fail", "scheme": "libp2p Noise (X25519)", "why": "Node-to-node transport uses libp2p with classical Noise/X25519 key exchange; PQ/hybrid is not deployed.", "sources": ["https://github.com/starknet-io/starknet-p2p-specs"] },
    "5.2": { "verdict": "fail", "scheme": "libp2p peer IDs", "why": "libp2p node identity keys are classical.", "sources": ["https://github.com/starknet-io/starknet-p2p-specs"] },
    "5.3": { "verdict": "fail", "scheme": "Classical TLS", "why": "RPC / API connections use classical TLS." },
    "5.4": { "verdict": "na", "scheme": "", "why": "No protocol-level stealth-address / on-chain key-agreement standard is deployed (privacy features are emerging)." },
    "5.5": { "verdict": "na", "scheme": "", "why": "Application-layer encryption / privacy is emerging, not a core deployed feature." }
  }
}