Starknet publicly names every active primitive. The 2026-06-30 migration roadmap also enumerates the remaining Pedersen surfaces (global state trie, per-contract storage tries, contract-address derivation, public_keys_hash), improving inventory completeness; the protocol cryptography reference page does not yet reflect the BLAKE2s-256 change (release-notes and roadmap document only).

Proof layer is structurally PQ-safe (FRI-based STARK, hash bound). User-signature layer and remaining Pedersen-based commitments are Shor-vulnerable. The v0.14.3 BLAKE2s-256 change removed one Shor-vulnerable surface (OS program/config hash, live mainnet 2026-07-06); the state trie, storage tries, and contract-address derivation remain Pedersen.

Hash-based count = 1 deployed. No lattice / code / isogeny family at signature layer in mainnet production. S2morrow (lattice-Falcon) demo and a third-party standard Falcon-512 Sepolia verifier exist but neither is the default account scheme. Diversity Cap (lowered to 60 in v3.1) does not fire here because there is no second family deployed at 5b/5c, credit for hash-based proof layer caps at 10 (hash-only).

STARK-curve ECDSA ≈ 125-bit classical / 0-bit PQ for signatures; Pedersen ≈ ~125-bit classical (DL-bound on STARK curve); Poseidon ≈ 128-bit classical hash, research-tier; S-two FRI ≈ 128-bit hash-bound conjectured PQ. No NIST-standardized PQ primitive is mainnet-active in user-signature path. Proof layer aligns with hash-based PQ assumptions but is not a NIST-certified primitive.

Formal-verification toolchain exists (public Lean-based formal proofs of Cairo programs maintained in the vendor's own repository); library_provenance: scure-starknet JS cryptography library independently audited (Kudelski Security, 2023-09, audit funded by the vendor); constant_time: standard for STARK-curve ECDSA implementations; statefulness: stateless schemes throughout; cryptanalytic_tier: tier-1 ECDSA, tier-2 Keccak/Blake2, tier-4 Poseidon (research-grade ZK hash), Pedersen tier-1 by hardness (DL) but binding broken by Shor. No public third-party audit of the Stone or S-two provers could be verified.

Every account is a contract; the signing public key is written to contract storage at deployment and sits in plaintext storage indefinitely (counterfactual deployment means practical exposure timing resembles reveal-at-first-use, but there is no hash-hiding of the key once the account is deployed). Native AA permits per-account key rotation, social recovery, and signer-scheme upgrade, so active-key Forge exposure is structurally mitigated relative to externally-owned-account architectures, but the default scheme is ECDSA over the STARK curve. Chain TVL ≈ $162M (research date, on-chain analytics aggregator), down from ≈ $222M-247M during April 2026 per the same aggregator's historical series. A session-keys standard (SNIP merged 2026-03-03) also keeps bounded-scope delegated keys live between owner signatures.

Chain age ~4.8 years (testnet 2021, mainnet alpha 2021-11; STRK token 2024-02) bounds the dormant-coin surface. AA gives dormant accounts a re-key path ONCE owners act, but unmoved accounts whose keys are now lost remain Shor-vulnerable.

Historical STARK-curve ECDSA signatures are post-Shor forgeable. Inclusion-validity is, however, settled by FRI-based STARK proofs (PQ-safe), so historical state-transition integrity is independent of Shor-breaking the signature curve. Re-org via signature forgery is moot once a block is L1-final (Ethereum settlement).

No hybrid PQ KEM is documented anywhere in the stack. Client RPC is JSON-RPC over HTTPS through node providers (standard classical TLS); the sequencer/full-node P2P transport encryption scheme is not publicly named (checked sequencer repo documentation; evidence-thin, flagged for re-sweep). StarkGate L1-L2 messaging is plaintext on-chain; the bridge does not introduce a PQ-relevant encryption surface. Sequencer operation is centralized (StarkWare-operated), which concentrates the harvestable transport surface.

Pseudonymous, transparent ledger; full tx graph visible via L2 explorers (Voyager, Starkscan) and by inspection of L1 blob/calldata. SNIP-36 in-protocol proof verification (live mainnet since v0.14.2, 2026-04-13; keccak-builtin extension in v0.14.3) lets adopting applications reference off-chain execution via proof/proof_facts fields on Invoke V3 transactions instead of posting full calldata, a shipped protocol primitive that reduces exposed calldata for applications that opt in; no default wallet flow uses it, and state diffs remain public.

All user transactions currently flow through the StarkWare-operated sequencer set and its centralized feeder gateway (the protocol's own staking documentation states Starknet is currently still centralized), concentrating full mempool visibility at a single operator. Hosted RPC providers offering Starknet endpoints (Alchemy, Infura, Blast API among them) add a second aggregation layer; no public measurement of per-provider traffic share exists. Validator metadata retention policy not publicly declared.

StarkGate canonical bridge correlates L1↔L2 addresses by message-passing contract. Third-party bridges (Orbiter, LayerSwap among them) compound source-dest correlation across chains.

No mainnet shielded pool. Retroactive de-anon under Shor is limited to: (i) recovery of STARK-curve / secp256k1 private keys from public keys, allowing historical address-to-owner attribution if any off-chain identity link existed; (ii) Pedersen commitment binding broken (relevant for application-layer commitments, not transaction privacy). Tx graph itself is already public.

No structural mix layer. No on-chain commit-reveal scheme as a default. Privacy efforts on Starknet are application-layer prototypes; no mainnet privacy-default.

Native AA from genesis means signature-scheme migration is per-account contract logic, not protocol fork. New signature verifier (e.g., Falcon-512, ML-DSA) ships as a library/contract; account contracts opt in. The v0.14.3 Pedersen-to-BLAKE2s-256 swap for OS program/config hashes demonstrates version-gated protocol-level crypto replacement in production (blocks below the activation height keep Pedersen, later blocks use BLAKE2s-256). Protocol-level hash agility for the state trie remains constrained: Pedersen commitments are baked into state-trie binding, and the migration roadmap itself states no public specification, implementation, released toolkit, or developer workflow exists yet for legacy Pedersen-based contract storage.

Every account is a smart contract since day one; per-account signature scheme, per-account rotation, multisig, social recovery deployed on mainnet by Argent X (Ready) and Braavos for years. S2morrow demonstrates a Falcon-512 PQ-signed account-contract working in browser across Devnet/Sepolia/Mainnet target environments, and a separate third-party verifier executing Falcon-512 verification per the round-3 submission specification (SHAKE-256 hash-to-point; FN-DSA has no published draft or final FIPS) is deployed and transaction-verified on Sepolia testnet. A community-drafted pluggable-signer SNIP (2026-05-12, mainnet-declared reference implementation, third-party Cairo audit) standardizes a ten-kind signer interface (Ed25519, secp256k1 variants, P-256/WebAuthn, STARK-curve, BLS12-381, ES256 JWT), but none of its ten kinds is post-quantum. No client-layer PQC integrated path declared at sequencer/prover level.

Multiple coordinated upgrades: Cairo v1 transition (2023-2024; the originally-planned 'regenesis' state migration was replaced by a gradual deprecation path, with CairoZero class declarations blocked from 2024-03-25), v0.13 series, v0.14.0 (mainnet 2025-09-01), S-two prover swap (production Q4 2025), v0.14.1 (mainnet 2025-12-10, after two publicly-posted postponements from 2025-11-25), v0.14.2 (testnet 2026-03-23, mainnet 2026-04-13), v0.14.3 (testnet 2026-06-22, mainnet 2026-07-06). Roughly quarterly cadence, each preceded by public prerelease notes naming testnet and mainnet activation dates, coordinated under the 12-member Security Council's upgrade authority (SNIP-25). No contested forks.

Architecturally trivial via AA, an account contract can require AND-composed STARK-curve + Falcon signatures, or OR-composed with commit-to-hash. No mainnet hybrid signature scheme is the default account class today. The 2026-06-30 migration roadmap replaces the prior dateless Phase-4 mention with a structured plan (accounts, proofs, protocol cryptography, existing deployments, Ethereum-facing dependencies) and one shipped component (v0.14.3 BLAKE2s-256 on mainnet), but it publishes no dates for future phases, no hybrid composition spec, and the consensus-signature language quoted in roadmap coverage (post-quantum signatures 'such as Falcon-512') describes a pure-PQ target, not a classical+PQ hybrid.

No stateful-hash scheme (XMSS/LMS) in scope. Stateless schemes (Stark-curve ECDSA, Falcon, Poseidon) throughout.

Block production today runs as four StarkWare-operated sequencer processes taking turns and running Tendermint consensus on every block (per the v0.14.0 prerelease notes, mainnet 2025-09-01); staking is live but validators only attest (phase 2 of 4 per protocol docs). No public source names the signature scheme used in sequencer consensus or validator attestation, and no BFT arrangement or aggregation scheme is published for the decentralized validation phase (SNIP-33) beyond its naming (checked staking and validator-onboarding docs; a documented absence). No Shor-vulnerable BLS aggregation is documented at consensus. Roadmap coverage formally declares a PQ consensus-signature direction (post-quantum signatures 'such as Falcon-512'), a declaration that did not previously exist, but with no merged spec, no implementation, and no date it stays below the declared-with-merged-spec threshold.

Mainnet PQC %: estimated <1% of user signatures; ~100% of proof-layer artifacts are STARK/FRI-based (PQ-safe by family). v3.1.0 5a is defined on user-signature traffic; Starknet's structural FRI proof-layer is PQ-safe but is not a 'signature.' Conservative score reflects no mainnet PQ signature default.

S-two (Circle STARK, FRI-based, PQ-safe-by-family) has been the production prover since Q4 2025, that is shipped PQ-safe code in the proof path. The v0.14.3 Pedersen-to-BLAKE2s-256 OS program/config hash change is merged in the StarkWare sequencer client (commit trail spanning 2025-07 through 2026-06, merged 2026-06-16) and mainnet-mandatory since 2026-07-06; parity in third-party full-node clients (Juno, Pathfinder) is unconfirmed. No ML-DSA / Falcon / SLH-DSA verifier in any default account class. S2morrow Cairo verifier is publicly available but is research code by labelling; a separate third-party standard Falcon-512 verifier is deployed and transaction-verified on Sepolia testnet only, unaudited.

Block production is four StarkWare-operated sequencer processes taking turns under Tendermint consensus (since v0.14.0, mainnet 2025-09-01), with a still-centralized feeder gateway. Decentralized validation (SNIP-33) was stated in the v0.14.2 prerelease notes as planned for completion within 2026; not live at research date. No PQ keys in the current sequencer signing path.

VOIDED to 0 per v3.1 (5a effectively zero in user-signature path). The 2026-06-30 migration roadmap publishes phase structure but zero dated future milestones and no enforcement mechanism, so the count of enforcement-backed dated PQ milestones remains 0 even before the void. Track record on the one dated PQC-relevant milestone published (v0.14.3 BLAKE2s-256, testnet 2026-06-22, mainnet 2026-07-06): it shipped on its named dates, with no postponement posted and the mainnet change confirmed live.

Announced PQ claims trailing 12 months ≈ 18: S-two-is-PQ-safe posts; the 2026-06-30 migration roadmap and its phases (Falcon-512 consensus-signature direction, trie/address hash-migration direction, legacy-contract tooling, Ethereum-facing dependencies); press amplification of the roadmap announcement; and the roadmap's claim of a mainnet-demonstrated Falcon-512 account, single-sourced and uncorroborated. Shipped PQ-relevant mainnet changes ≈ 3: S-two FRI proof layer since Q4 2025; v0.14.1 BLAKE compiled_class_hash since 2025-12-10 (gas-motivated); v0.14.3 BLAKE2s-256 OS program/config hash since 2026-07-06 (quantum-motivated). Both sides of the ratio grew over the trailing twelve months. Operative ratio is ≈1.5, borderline under the proof-layer-inclusive reading: the dominant announced artifact labels its own not-live items explicitly, the opposite of washing behavior, but under a strict signature-only definition shipped PQ signing is 0 and the ratio is far higher. No automatic deduction.

VOIDED (undisclosed at production-signature level, no PQ scheme is the default; S2morrow Falcon-512 measured at 9.5M L2 gas, 62 felts calldata, 65% savings vs secp256r1 in the demo, but this is not the production signing footprint).

Argent X (Ready), Braavos, Ledger (via wallet integrations). PQC roadmap published by named top-3 vendor: 0. The Ready (formerly Argent) and Braavos blogs were checked directly: neither carries any PQC or quantum post, a shipped PQ signing default, or a dated PQC roadmap.

StarkGate (canonical; contracts upgraded to v3.0.0 alongside v0.14.2 with no PQC-relevant change), plus third-party bridges (Orbiter, LayerSwap among them). PQC roadmap: 0.

No custodian-published, Starknet-asset-specific PQC roadmap could be located. The set of custodians offering Starknet asset support is itself not independently verified (evidence-thin); no positive evidence exists to award points.

Hosted RPC providers offering Starknet endpoints include Alchemy, Infura, and Blast API. No Starknet-specific PQC statement from any RPC or infrastructure provider could be located, and the PQC posture of provider TLS endpoints is not measured (evidence-thin). HSM/TEE provenance for sequencer keys not publicly disclosed.

Block production = four sequencer processes, all StarkWare-operated (Tendermint rotation since v0.14.0); Nakamoto coefficient at the operator level = 1. STRK-staking validator set exists for attestation but does not yet sign blocks at consensus quorum; the decentralized validation phase (SNIP-33) was stated in the v0.14.2 prerelease notes as planned for completion within 2026, not live at research date.

Cairo v1 transition, v0.14.0, S-two swap, and the v0.14.1 / v0.14.2 / v0.14.3 series all coordinated without contested fork, on a roughly quarterly cadence with testnet and mainnet activation dates published weeks ahead. v0.14.2 and v0.14.3 shipped on their originally-named dates; v0.14.1's mainnet date slipped twice (2025-11-25 → 2025-12-03 → 2025-12-10), each slip publicly posted in advance in the same prerelease thread. Demonstrated upgrade capacity is high.

Starknet Foundation (executive director public, board public); StarkWare (founder-CEO public). The 2026-06-30 post-quantum migration roadmap is a published document with a named public lead: the StarkWare CEO announced it and is quoted authoring it. Deductions: the roadmap is StarkWare's document rather than a Starknet Foundation or cross-org working-group mandate, and no separate PQ working group, standards lead, or coordination body distinct from StarkWare is named.

STRK launch 2024 had governance turbulence (airdrop disputes); no demonstrated coordinated cryptographic change under live attacker pressure. Independent third-party governance scrutiny of protocol upgrades is documented: a named external governance team publicly recorded an against position on the v0.14.3 proposal bundle over a fee-mechanism incentive concern.

No canary, honeypot, or rate-limit tripwire embedded in consensus declared. The Security Council's pause/unpause authority over core contracts is the closest emergency mechanism; its signing threshold is not publicly stated in the protocol documentation checked.