Featured

New research sharpens quantum attack estimates.

Read the ecdsa.fail publicationRead the ecdsa.fail publication
StarkWareQuantum Hub

Quantum readiness hub

Starknet’spost-quantummigration.

Hash-based proofs. Programmable accounts.

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.

View the five migration surfaces

Migration register

Current status by migration surface

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.

Public evidence

Proofs

Structural propertySTARK proving assumptions

What is true today

The Starknet proving layer was designed for post-quantum security without relying on elliptic-curve hardness assumptions.

What remains

This advantage is limited to the proving layer. Security still depends on the chosen hashes, parameters and implementation.

Who can change it

StarkWare develops the proving system. Protocol-level changes adopted by Starknet are subject to governance.

Public evidence

No component-level evidence record is published for this surface yet.

Starknet protocol cryptography

What is true today

Starknet v0.14.3 replaced Pedersen with a BLAKE2s-256-based construction for the OS program and configuration hashes. The change is live on Mainnet.

What remains

The trie and contract-address changes are published direction, not live. Storage-map key derivation and tooling remain separate work.

Who can change it

StarkWare engineering develops these changes. Protocol activation is subject to Starknet governance.

Public evidence

Existing deployments and migration

What is true today

StarkWare's published roadmap says its team is researching migration tooling for existing contracts that use Pedersen-based storage maps.

What remains

There is no public specification, implementation, released toolkit or developer workflow yet.

Who can change it

StarkWare is researching the tooling. Contract teams would decide whether to use any resulting migration path.

Public evidence

Ethereum-facing dependencies

What is true today

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.

Public evidence

Continue with the roadmap

Starknet’s quantum readiness roadmap

See how STARK proofs and native account abstraction shape Starknet’s path toward post-quantum security.

Read the quantum roadmap

Last updated: 19 August 2026.

Contract-address derivation evidence opened in the surface reader