Phase 1 — Sealing the On-Chain Attack Surface
The first implementation block targets fresh on-chain activity. Pedersen hashing, which inherits elliptic-curve assumptions, is being replaced with BLAKE2 across three subsystems: the state commitment trie, contract address derivation, and the OS configuration hash. The OS configuration hash update is scheduled for mainnet deployment in early July 2026. Concurrently, Falcon-512 post-quantum signature options are being integrated into account contracts by OpenZeppelin. This work is structurally enabled by Starknet's native account abstraction, which permits quantum-resistant signature schemes to be deployed at the contract layer without breaking protocol-level consensus semantics. The architectural property is not incidental: it eliminates the need for a hard fork to swap validation primitives.
Phase 2 — Retrofitting the Legacy State
Phase 2 extends the migration envelope to existing on-chain deployments. Automated native migration toolkits are being introduced to allow developers to upgrade legacy storage slot key derivations without manual data migration or contract interface disruptions. The operational consequence is asymmetric: new contracts inherit PQ safety by default at deployment, while pre-existing state must be re-keyed through tooling rather than consensus forks. For oracle publishers and middleware maintainers holding long-lived contracts on Starknet, this defines a concrete migration obligation rather than an optional upgrade path.
Phase 3 — The Ethereum-Bound Corridor
The third block addresses the boundaries Starknet cannot unilaterally secure. The L1-to-L2 bridge messaging framework currently relies on quantum-vulnerable secp256k1/r1 system calls. The state-diff data availability layer utilizes elliptic-curve-based KZG commitments inside EIP-4844 blobs. Both surfaces are gated by Ethereum's independent post-quantum migration timeline, and their remediation is explicitly conditional on upstream cryptographic upgrades — a dependency that preserves cross-chain messaging and data availability transparency but binds Starknet's worst-case exposure window to Ethereum's own transition cadence.
Viability Assessment
Starknet's proving substrate was hash-native from inception. The roadmap formalizes the cleanup of residual ECC dependencies and acknowledges, without qualification, that the L1↔L2 corridor remains cryptographically coupled to Ethereum. For developers exposing off-chain data through Starknet contracts, the constraint resolves into a binary condition: in-protocol signature and state derivation primitives become PQ-safe on the published schedule, while bridge-finalized data feeds inherit their security posture from Ethereum's migration trajectory. The protocol's long-term viability against a cryptographically relevant quantum adversary is therefore conditional, not absolute — contingent on an external settlement layer that StarkWare cannot upgrade alone.