Starknet starts with two structural advantages: a proving layer designed for post-quantum security without relying on elliptic-curve hardness assumptions, and programmable account validation.
Post-quantum migration spans account authorization, proof-system assumptions, protocol cryptography, existing deployments and dependencies inherited from Ethereum. Live changes, demonstrations, roadmap work and external dependencies carry different labels.
Each component has its own status. The order does not show maturity or sequence.
Five migration surfaces
Public-source register
Accounts
Structural propertyNative account abstraction
What is true today
Programmable account validation lets a new account implementation adopt a post-quantum signature verifier without a breaking protocol change.
What remains
Existing accounts do not change automatically. Wallet support, signing, key management, recovery, custody, audits and adoption remain separate work.
Who can change it
Account developers choose validation logic. Wallet and custody teams decide whether to integrate it.
Under normal conditions, Starknet publishes state diffs to Ethereum as EIP-4844 blobs. This path uses Ethereum's KZG scheme. Calldata remains available.
What remains
KZG is one inherited dependency. Bridge and messaging remain separate Ethereum-facing dependencies.
Who can change it
Ethereum controls KZG. Starknet can use blobs or its calldata fallback. Bridge and messaging changes depend on Ethereum's migration.
Quantum Hub
